Secure health data storage can be the easiest part of your startup

Don’t be scared away from building your idea just because it involves managing health data. The news is full of scary stories about data breaches and privacy regulations, but the health platform we’ve built at LifeOmic was designed to make building health software and devices easier.

Here is what I’m assuming:

• You have the idea and skills for the next killer health wearable or health app
• You know you need to store your data in the cloud
• Building and securing a health data storage system in the cloud is not something you want to do
• You won’t let that stop you from building your app or device

I’ll show you how to start storing health data in five steps. I’m going to pretend you are looking to add cloud storage for a new digital scale. You’re going to build something more interesting than that, but scales are easy to demonstrate with.

Step 1 — Create an Account

The LifeOmic Platform is our health data platform. Our collection of health services can do a lot more than just data storage. You can read all about our platform if you are curious about what else we can help with.

You can get an account two ways:

1. You can visit the Platform marketing page and request a demo.
2. You can take a shortcut and DM me on Twitter or send me an email. If you are reading this article, I’d love to shortcut your account setup and hear what you are building.

A huge advantage of storing data in the LifeOmic Platform is that we’ve already handled the security and compliance of your data storage. The platform is continuously audited against multiple robust frameworks and regulations such as HIPAA and HITRUST. When you build on top of the LifeOmic Platform, you inherit much of this work and it can greatly reduce your compliance obligations. Checkout https://security.lifeomic.com/ for more details.

Step 2— Create a Project

In the LifeOmic Platform, all data is organized into “Projects”. Some APIs refer to projects as “datasets”, but the meaning is the same. A Project holds Patients and their observations. For this example, we’ll create a single project to hold all data, but having multiple projects is possible if segregating your users makes sense for your project.

After creating the project, click on it in the project list, and the URL should show the project ID like this:
https://apps.us.lifeomic.com/phc/project/projects/<project-id>

Save the project ID value for steps 4 and 5.

Step 3— Create an API key

The easiest way to make requests to the LifeOmic Platform is with an API key. That’s just one method of authentication, but it’s quick to set up and the code is simple. Follow the instructions and make sure to record the API key for use in steps 4 and 5.

Step 4— Create a Patient

A “Patient” is the term the LifeOmic Platform uses for the subject of observations. It comes from the FHIR specification, but don’t be scared away by the medical terminology. If you are building a non-clinical project, just think of Patient as “Person.”

The only non-obvious lines in the code above are the ones for the meta attribute. In the LifeOmic Platform, all data lives inside a Project, and when resources are created, they must reference the project that owns them. The project ID is the one you kept from step 2.

Step 5— Store health data

The last step is what you came for. Remember, I’m pretending that you are building a digital scale, so in the code below I’ll show how to store body weight. You can store whatever values you’d like.

This API request is less obvious than the patient creation code above. Hopefully the inline comments give you a vague idea, and I’ll explain about coding at the end of the article.

That’s it. You’ve stored your first bit of health data for a user. Now it’s time to dig into the details of what else is possible.

What is FHIR?

FHIR is a standard that defines both the terminology and data formats for health data. Like most standards, it’s not meant for a friendly read. It seems more complicated than you need at first, but it’s more useful than you expect.

One valuable thing FHIR has done is define a terminology to use for tracking health related data. The examples above show Patients and Observations, but there are many more resource types. Using a FHIR storage system and working with the terminology they define means better interoperability with systems like Apple HealthKit and EMR like Epic and Cerner.

If you care about data interoperability, you should pay extra attention to the “coding” feature of FHIR. While most systems store just a value, like “60”, FHIR includes a code for each value to give it meaning. Without codings, 60 could mean a 60 beats per minute heart rate, or it could mean the weight of a 60 lb child. Codings on each value make sure that the data can be interpreted by others system as the data moves around.

It’s worth skimming the FHIR specification and considering how your data model fits into their terminology. You should think of FHIR databases as another alternative to SQL or NoSQL.

Start Building

If you are considering building a new health app or device, I’d love to hear about it. DM me on Twitter or send me an email and let’s talk about what you’re trying to do. Don’t worry; I’m a developer, not a sales guy. I like to talk about cool ideas and with people who build.