“Move fast and break things” is the Silicon Valley motto.
This works for many industries but not for healthcare and medtech. There’s no space for “half baked” when it comes to products dealing with patient data.
You avoid this by building a team with the right people and the right expertise.
It’s tempting to jump straight in with a bunch of experienced developers and business analysts. This is how it’s been on most projects I’ve worked on — even in healthcare.
Problem is you’re missing at least five people. The absence of any one of these can cause your product to fail or founder.
Let’s say you’re building a new product with FHIR at the center. Who do you need?
1. A FHIR subject matter expert (SME)
FHIR is not just another database. Your C# or Java developers will not “pick it up as they go along,” not without a litany of false starts, poor decisions and costly architectural pivots.
In case you’re wondering, there is no “FHIR for Devs” book you can buy on Amazon.
You need a FHIR expert on your team — from Day 1.
Here are a few things they should be able to discuss with you at your first meeting, all of which play a part in the early stages of your project.
- Why the latest version of FHIR might not be the best choice
- Mapping your data model to FHIR
- What NOT to store in FHIR
- How to expand FHIR using Extensions
And here are some things they can help your product architect with:
- Profiles and validation
- Custom SearchParameters
- Capturing the source of the data in FHIR
A FHIR SME will start the team and the project off on the right track and help avoid costly mistakes. Their job is not just to train, but to point out the unknowns so they can be factored in and dealt with.
Bonus points if they can code.
2. A Terminology expert
Getting terminology wrong is a mistake that can de-rail a healthcare project as it approaches completion.
The importance of terminology is not obvious in the early stages of a project when the focus is often on getting data flowing into and out of FHIR, and on UI screens that can be shown to the business and to potential customers.
If your dev team has little experience of healthcare data — as is often the case — they may assume that the wording and phrasing used inside the product can be defined by them.
After all, a broken leg is a broken leg. How complicated can that be?
Very, very complicated.
Terminology used in healthcare is often mandated by regulation. Code systems such as SNOMED CT, Loinc and ICD10 contain many hundreds of thousands of inter-related terms that are used all over the world.
You can’t just make this stuff up.
It is highly unlikely that your product can be effectively used in a real world setting without utilizing these external code systems.
It is highly likely that “rolling your own” terminology will lead to a major rewrite before or shortly after a production release.
A terminology expert should be able to guide you in which terminologies you need to use, as well as how to incorporate them into your product.
They should play a central role in the definition of your data model.
3. A healthcare domain expert
If you’re sending and receiving data from Hospital IT systems (HIS), you will need a HL7 expert who can guide you on what to expect from the HIS and on the differences you are likely to encounter between hospitals.
If you’re building an application that deals with health insurance data: claims, pre-authorizations, payments, etc., you will need an expert in that field.
Genomics, clinical trials, research, medications?
The same.
While all aspects of healthcare can be stored in FHIR resources, a domain expert is needed for the specific area your product targets.
If you don’t have one on your team or providing insights as your team works, you will make incorrect assumptions and poor decisions based off those assumptions.
Better to pay that price up front by placing a domain expert on your team as early as possible.
4. A medical consultant
This person might be a doctor, a nurse practitioner or a lab technician depending on the product you’re building.
The commonality is that they all have real world medical experience in the area your product serves. They may know nothing about FHIR, but they do know what data needs to be accessed and what data needs to be saved.
Companies with a startup mindset almost always miss this. They underestimate how significant their lack of medical knowledge is, and how much they will get wrong as a result.
They assume that a product demo with a friendly doctor every few months will keep them on the right path.
It won’t. Even companies who have been in the healthcare space for decades get this wrong, carefully inviting medical expertise into the project at a late stage and in a limited way.
Software developers have never worked in an operating theatre. They don’t know what a nurse needs at a specific point in time, what happens in a lab when samples are received, how an emergency admission differs from a scheduled procedure.
The sooner you get a medical expert on board, the sooner your team will stop making time consuming mistakes.
5. Data compliance experts
Just about every country in the world has legislation and regulations affecting how patient data can be stored and used. Your product must meet these requirements before it can be used in the real world by real people.
Your devs cannot tell you what these requirements are. They may have read up a little, but Google is not going to answer these questions in a confident way.
You need regular meetings with lawyers and with data compliance experts covering the countries and regions your product will be used in.
Europe has different regulations than the US. Even countries within the EU can differ considerably.
You may not have a lawyer at every team meeting, but they should have a large part to play in your project — especially as it it moves closer to a production release.
Let’s recap.
You’re building a product in the healthcare or medtech space. The data is stored in a FHIR server or servers.
You need:
- FHIR expertise
- Terminology expertise
- Domain expertise
- Medical knowledge expertise
- Legal & data compliance expertise
Every healthcare project I’ve worked on began its life without any of the above. If that sounds crazy, then I have to agree.
But all successful projects went to production with input from all of these experts. The period from start to finish was often filled with false starts, code rewrites, extended deadlines and much hair pulling and frustration — caused by the absence of one or more of these five people.
You can start your new project without them, but you won’t finish it without them.
---