We are ridiculously good at mastering data. The data is clean, multi-sourced, related and we only publish it with resulting levels of decay that guarantee the data is current. We chose the HL7 Reference Information Model (RIM) to land the data, and enable exchange of the data through Fast Healthcare Interoperability Resources (FHIR®).

We are also a high performing, full stack team, and like to keep our operational resources on task, so managing the underlying infrastructure to host the FHIR® data repository for purposes of ingestion and consumption is not in the cards for us. For this, we chose the FHIR® Accelerator Service to handle storage, credentials, back up, development, and FHIR® interoperability.

Our data is marketable, and well served as an API, so we will monetize it. This means we need to package our data/api up for appropriate sale — which includes: a developer portal, documentation, sample code, testing tools, and other resources to get developers up and running quickly against our data. We need to focus on making our API as user-friendly as possible, and give us some tooling to ward off abuse and protect our business against denial service attacks. For the customers using our data, we chose to use Google Cloud's Apigee Edge.

With our team focused and our back office entirely powered as services, we are set to make B I L L I O N S, and this is an account as to how.

Provisioning

High level tasks for provisioning in the FHIR® Accelerator Service and Google Cloud's Apigee Edge.

FHIR® Accelerator Service

Head over to the AWS Marketplace and subscribe to the InterSystems FHIR® Accelerator Service, or sign up for a trial account directly here.
After your account has been created, create a FHIR® Accelerator deployment for use to store and sell your FHIR® data.

After a few minutes, the deployment will be ready for use and available to complete the following tasks:

1. Create an API Key in the Credentials section and record it.
2. Record the newly created FHIR® endpoint from the Overview section.

Google Cloud Apigee Edge

Within your Google Cloud account, create a project and enable it for use with Apigee Edge. To understand a little bit of the magic that is going on with the following setup, we are enabling a Virtual Network to be created, a Load Balancer, SSL/DNS for our endpoint, and making some choices on whether or not its going to be publicly accessible.

Fair warning here, if you create this as an evaluation and start making M I L L I O N S, it cannot be converted to a paid plan later on to continue on to making B I L L I O N S.

Build the Product

Now, lets get on to building the product for our two initial customers of our data, Axe Capital and Taylor Mason Capital.

Implement Proxy

Out first piece of the puzzle here is the mechanics of our proxy from Apigee to the FHIR® Accelerator Service. At its core, we are implementing a basic reverse proxy that backs the Apigee Load Balancer with our FHIR® API. Remember that we created all of the Apigee infrastructure during the setup process when we enabled the GCP Project for Apigee.

Configure the Proxy

Configuring the proxy basically means you are going to define a number of policies to the traffic/payload as it either flows to (PreFlow/PostFlow) to shape the interaction and safety of how the customers/applications behave against the API.

In the below, we configure a series of policies that :

1. Add CORS Headers.
2. Remove the API Key from the query string.
3. Add the FHIR® Accelerator API key to the headers.
4. Impose a Quota/Limit.

A mix of XML directives and a user interface to configure the policy is available as below.

Add a Couple of Developers, Axe and Taylor

We need to add some developers next, which is as simple as adding the users to any directory, this is required to enable the Applications that are created in the next step and supplied to our customers.

Configure the Apps, one per customer

Applications is where we break part our product and logically divide it up to our customers, here we will create one app per customer. Important note here that in our case for this demonstration, this is where the apikey for that particular customer is assigned, after we assign the developer to the app.

Create the Developer Portal

The Developer Portal is the "clown suit" and front door for our customers and where they can interact with what they are paying for. It comes packed with some powerful customization, a specific url for the product it is attached to, and allows the import of a swagger/openapi spec for developers to interact with the api using swagger based implemented UI. Lucky for us the Accelerator Service comes with a swagger definition, so we just have to know where to look for it and make some modifications so that the defs work against our authentication scheme and url. We don't spend a lot of time here in the demonstration, but you should if you plan on setting yourself apart for the paying customers.

Have Bobby Send a Request

Let's let Bobby Axelrod run up a tab by sending his first requests to our super awesome data wrapped up in FHIR®. For this, keep in mind the key that is being used and the endpoint that is being used, is all assigned by Apigee Edge, but the access to the FHIR® Accelerator Service is done through the single key we supplied in the API Proxy.

Rate Limit Bobby with a Quota

Let's just say one of our customers has a credit problem, so we want to limit the use of our data on a rate basis. If you recall, we did specify a rate of 30 requests a minute when we setup the proxy, so lets test that below.

Bill Axe Capital

I will get in front of your expectations here so you wont be too disappointed by how rustic the billing demonstration is, but it does employ a technique here to generate a report for purposes of invoicing, that actually removes things that may or may not be the customers fault in the proxy integration. For instance, if you recall from the rate limit demo above, we sent in 35 requests, but limited things to 30, so a quick filter in the billing report will actually remove those and show we are competent enough to bill only for our customers utilization.

To recap, monetizing our data included:

• Safety against abuse and DDOS protection.
• Developer Portal and customization for the customer.
• Documentation through Swagger UI.
• Control over the requests Pre/Post our API

... and a way to invoice for B I L L I O N S.