When entering the world of health tech you'll likely be overloaded with a lot of standards like HL7-FHIR, SNOMED-CT, OMOP CDM. It's not always obvious to distill the added value of those standards and one can easily get caught up in the hype around them. Fortunately, we at Tiro.health have been exploring and implementing several of those standards π
In this blog post, we'll discuss the most important standards we've encountered and highlight what they can mean for you as a health tech enthusiast, developer, or entrepreneur.
Before discussing specific standards, let's define what a technical standard is: It is an agreement on how a repeatable technical task is executed. The standard is often the result of consensus between various respected stakeholders in the field. Examples of such standards are HTML. Contrary to the consensus-based establishment of standards, there exist best practices or technologies from private companies that emerge as a de facto standard because everybody uses them. PDF and MS DOC files are well-known examples of such de facto standards.
Most healthcare systems have a large number of stakeholders that need to work together. This is why standards are important! As a health tech company, it's hard to win playing solo. You need to cooperate and communicate with other players, often using technology standards.
A tour of healthcare standards
The healthcare standards that we will discuss have one major purpose in common: interoperability. An interoperable system is like a polyglot human. It indicates that your system can 'speak' with other systems following one or more standards. The role of the standards is to have a common language to speak which each other.
The specific standards we will discuss in this article are SNOMED-CT, FHIR, LOINC, and OMOP CDM, SMART-on-FHIR. I'll try to answer what the standards are about and why you may need them. You'll notice that I have split up FHIR into two groups: FHIR Resources and FHIR REST API, Messages and Documents, since FHIR itself is a beast with many heads.
In general, what purpose do these healthcare standards have? It's hard to have a single answer. In order to provide a clear answer, I have split them up into four broad categories: terminology, information models, exchange, and security.
1. Codes and terminology
People who have designed forms or questionnaires in the past probably know that there is a lot of work in translating answers with similar meanings to the same value or code in your spreadsheet. Especially in medicine where you have tons of synonyms, acronyms with the same meaning: myocardial infarction, MI, heart infarct, cardiac infarct. For us humans, this is clear, but this isn't practical for a computer program π€·ββ.
This is where terminologies come into play. The most important terminologies are SNOMED-CT, LOINC, and UCUM. But unfortunately, there are many more. Often you'll hear about ICD-9, ICD-10, and many countries and even hospitals have their own terminologies. The main goal of medical terminologies is to map medicine concepts to a unique code or identifier.
In SNOMED-CT myocardial infarction, MI, heart infarct, cardiac infarct, hartinfarct (dutch), infarctus cardiaque (french) are all mapped to the same code [22298006]. This removes a lot of ambiguity for developers and data analysts when writing software.
On top of that, SNOMED-CT has also a lot of medical knowledge incorporated π§ . Each term in SNOMED-CT has a computer-readable definition that can help programmers to interpret specific medical terms. Say you want to retrieve all patients with heart diseases then SNOMED-CT allows you to resolve that myocardial infarction is also heart disease. Needless to say that this is a very powerful system for data analytics π In general SNOMED-CT is focused mainly on general medical terms.
LOINC on the other hand is very much focused on observations and measurements π§ͺ. It is especially good in providing a specification on how a measurement is made. A LOINC code [41653-7] provides you basically the following info:
What substance or entity is being analyzed? β Glucose
What characteristic of the substance/entity? β mass concentration
In what timeframe is the measurement done? β a point in time
What specimens or system has been used? β blood capillary
What scale does the measurement value have? β quantity
What methodology has been used to perform the measurement? β glucometer
UCUM is your go-to standard for units of measurement and is very straightforward to use. It has human-readable codes and is largely adopted by LOINC for units.
2. Information modeling and content
How should we keep track of basic patient information? How do you record lab measurements? How do we reference the patient in our lab measurement record?
These are questions on which information models like FHIR Resources and OMOP CDM will give you an answer. Some older standards that you may find in this domain are HL7 CDA or HL7v2 and of course, there are many country-specific standards. Most of these standards make use of code systems like SNOMED-CT and LOINC to represent medical concepts in a meaningful way.
FHIR Resource and OMOP CDM may have the same purpose but theyβre quite different due to their different origins. They have also a different representation: FHIR resources have a tree-like structure that is lending itself to be represented as JSON or XML. OMOP CDM records are typically represented as records of a relational database.
A small example of a blood measurement to make this more tangible:
OMOP CDM
measurement_id: 2947483873
person_id: 274897373
measurement_concept_id: 3020491
measurement_date: 2013-04-02
measurement_datetime: 2013-04-02T09:30:10+01:00
measurement_type_concept_id: 32817
value_as_number: 6.3
unit_concept_id: 8753
provider_id: 27439277
FHIR
Observation
id: f001
text
identifier
status: final
code
coding:
system: http://loinc.org
code: 15074-8
display: Glucose [Moles/volume] in Blood
subject
reference: Patient/f001
display: P. van de Heuvel
effectivePeriod
start: 2013-04-02T09:30:10+01:00
performer
reference: Practitioner/f005
display: A. Langeveld
value
value: 6.3
unit: mmol/l,
system: http://unitsofmeasure.org
code: mmol/L
You'll notice that it's easier to make sense of the FHIR Observation resource compared to a single record from an OMOP CDM table. On the other hand, OMOP CDM is much more concise and seems efficient for storage. Everything in OMOP CDM is an identifier, while FHIR is much more verbose.
The reason for this is that FHIR resources are designed to be exchanged π€ and must be self-containing. So the resources must be at least understandable without the need for extra context information. OMOP CDM records are designed to be stored in a database for analytics. The OMOP CDM database is designed such that queries can be exchanged π instead of the data itself. Interoperability for OMOP CDM basically means that you can exchange your R or Python scripts containing SQL queries with other analysts.
Also, it will be easier to keep your OMOP Database consistent compared to your FHIR resources. Imagine a patient whose name changed but you've already sent plenty of FHIR Observation resources to other systems. It will be hard to notify all those systems on a simple name change.
When choosing standards, make sure to question their purpose and reason of existence π€. Pick the right standard for the right job. And once you've learned a standard don't apply it to every problem you encounter. Remember the wise words of Abraham Maslow:"If you only have a hammer, every problem looks like a nail."
βLet's wrap up this post, for now, to keep it concise. This post was about representing healthcare data points. In a subsequent post, we will continue the discussion on how to exchange healthcare data in a secure way.
β
