FHIR, Vanya Client

You have an idea for an app. What should you do on Day 1?

Let’s assume you’re happy with the app you’re about to build; that your idea has legs or at least the prospect of legs based on an itch you’re scratching or a gap that needs filling. (There’s an 800 page book in that sentence, but let’s not go there right now.)

How do you start? What do you do you on Day 1?

This is where I was last week. For a couple of months an idea for an app had been floating around in my head. It was to fill a gap I saw in the market for a particular type of developer tool that came to me after working on a greenfield project for a US healthcare company.

For two months I’d been sketching out features in my head and exploring the best tech to use to build the app. Three days ago I bit the bullet and spent a long afternoon implementing the early steps, the steps that while not required on Day 1, have real value down the road when put in place at the start.

I’ve built apps in the past without putting these early steps in place, releasing 6 months of work to an unsuspecting world. No audience, no potential users waiting for version 1, no one in a position to tell their friends or colleagues about it.

It was a wasted opportunity that set me back months in terms of exposure and feedback.

So here’s the afternoon’s work designed to prevent that from happening:

1. Designed a basic logo
I’m not a graphic designer. My logo design skills are almost non-existent, but Canva makes it easy to throw some text up next to an image and call it a logo.

My aim here was rudimentary branding such that anyone in the space I was targeting would recognise the app as belonging to that space. The fire image is recognisable as part of the FHIR database space — which is where my target user lives.

SQL on Fire logo

2. Built a one-page website that described the app

Very simple and very basic. I described in a few sentences what the app will do and who it’s for. I can now link to the site from anywhere — Twitter, LinkedIn, etc. While the app doesn’t exist yet, its shadow does in the form of a website.

I used a basic theme that I’d already purchased for multi-site use. No coding was required.

https://sqlonfire.com/ — “Query your FHIR database using SQL”

3. Added a ConvertKit sign-up form to start gathering email addresses

This is the most important section of my new one-page site, and arguably the sole reason the site exists at such an early stage. I want to start collecting email addresses from potential users and interested parties so that when I have a pre-release version I have someone to show it to. If I need feedback I’ll have people in the space to ask. When I go live, there’ll be at least a small audience waiting for it.

No more releasing into a void.

ConvertKit make creating and managing a sign-up form quick and easy. They handle opt-in emails, GDPR regulations, list management, etc. And it’s all free until you hit 1,000 email addresses.

4. Hosted the site

Hosting a one-page site does not require deep thought or careful planning. You don’t need AWS or Azure, you don’t need Cloudflare or Digitalocean droplets. All you need is somewhere to drop a static HTML page.

Keep it as simple as possible.

When the time comes to release your fully featured app, complete with online documentation and payment options, that’s the time to think about where best to host the site so that it can handle traffic spikes and all the complex bits you might have added to it.

I have a dozen legacy websites hosted on a UK server that I pay £100 a year for. Adding another site didn’t cost anything and took about 5 minutes.

Changing the DNS to point to the new host took another 5 minutes, at which point my site was live.

5. Added a free Let’s Encrypt SSL certificate to the new site

Another reason to go with the quick and easy shared hosting mentioned above — a one click install for Let’s Encrypt so that the site has a valid SSL cert. I tried doing this on Azure back in February for a new site I was building and wasted a good hour playing around with Let’s Encrypt before abandoning it and buying a cert instead.

You need an SSL certificate on your site, otherwise Google will penalise you and your visitors will see browser warnings that might turn them away.

6. Set up email on the new domain

My email accounts are all with Fastmail, a paid for email provider that handles multiple domain names and wildcard email addresses. Setting up my new email addresses for the new domain took about 10 minutes.

There were a number of steps involved, such as configuring the MX and SPF records, but it’s nothing I hadn’t done before.

As I already had a Fastmail account, it didn’t cost me anything.

The new one-page site is live now at https://sqlonfire.com/, complete with unattractive logo, brief app description and email sign-up form.

All the steps outlined above took about 4 hours to complete in a single afternoon and cost me $0. Today I’m writing code — starting work on the app itself. But I’m confident that when I have something ready to show down the road I won’t be scratching my head and looking around for users to show it to.

To hear more from me, you can follow me on Twitter or on LinkedIn.


Developers need better FHIR tools

Not long ago I worked on a greenfield project for a healthcare company. I was building the API that sat between the UI screens and the backend FHIR database, hosted on one of the larger cloud providers.

SQL on Fire

It was my first exposure to FHIR.

I’ve worked with databases of all kinds: SQL Server, Postgres, MySql, Sqlite, even DB2 back in the good old days. But this was my first encounter with a database that can only be accessed via an API.

If you’re unfamiliar with FHIR, it’s an open source data format for storing healthcare data. All the big cloud providers and a host of smaller companies provide FHIR database servers accessible via a commonly structured FHIR API. It’s growing in popularity. If you’re building a new app or starting a new project in the healthcare space, someone on your team or in the business will suggest using FHIR.

One of my first questions back in the early weeks of the project was: “Is there a desktop client I can use to access FHIR or do I have to use Postman?

Postman it was.

This may have been followed by “I can’t believe there’s no desktop client I can use to query FHIR!

For those unfamiliar with Postman, it’s the most popular API platform used to build and access APIs. It’s super easy to use, free for the most part, API agnostic and requires little in the way of technical know-how to get by.

But it’s generic, not optimised to work with any particular API or type of API over another. So while it works well as an API access tool, it’s limited as a FHIR database access tool.

I wanted a desktop client.

I work as a .NET contractor and I move around a lot: different companies, different industries, different problems with different solutions. When each contract ends I do a retrospective of my time there, asking myself questions such as: “Did I learn anything here that I can use?”, “Did I encounter anything this industry needs that is missing?” and “Can I take anything from my time here and build a product from it?

I was on a flight into Dublin airport last week when I did the retrospective on this particular contract. Usually I come up with lots of ideas but they tend not to be ideas with a commercial leaning, as in: interesting, but no one will pay for that as the pain isn’t big enough.

Not this time. My mind and my pen went right back to week one: “Is there a desktop client I can use to access FHIR or do I have to use Postman?

There should be.

Sure, it’s an API not a database. I might have to call it something else instead of a database client. But Postman is not a good enough tool for accessing FHIR APIs, not for developers building products and apps on top of FHIR. Developers want something more SQL-like. They need to be able to write a query not make a GET request in Postman.

When you’re building a new app or debugging Production, you want to move fast. You don’t want to be fiddling around with Postman and manually skipping through pages of JSON results to find what you’re looking for.

There are tools out there to help FHIR developers. There’s a .NET sdk provided by a Dutch company. There are CLI tools sitting on top of that sdk. There are companies providing FHIR servers who have their own tools exposed for use with their servers.

But I wanted a SQL-type desktop client that I could use against any FHIR API. Somewhere to build and store common queries that I could save and share with the team. An easy tool that allowed me to drill down into the FHIR data by clicking on Resource identifiers.

I wanted a cross platform desktop client for accessing FHIR APIs on Azure, AWS, Google and other FHIR servers. It doesn’t exist but it should.

Maybe I’ll build it.

To hear more from me, you can follow me on Twitter or on LinkedIn.