One of the main sources of confusion when starting an implementation is with FHIR system strings.
This field is ubiquitous across FHIR elements, but many developers who are new to healthcare don't understand its purpose or how to set it properly. They are used in even the most basic implementations, and even the sample data we provide for prototyping has many
So today, we're going to delve into
system strings to understand what they're for and how to use them!
System strings are commonly found on two distinct element types:
A common occurrence in healthcare is that the same entity (patient, practitioner, device, etc.) is present in many different systems, each assigning their own unique ID. With FHIR, we can neatly keep track of all these unique IDs using the
To avert any name collisions, each
Identifier has an associated
system string, which acts as a namespace for the identifier. This namespace is typically an absolute URL to ensure its global uniqueness.
Let's look at an example. Say we have two patients, Alice and Bob, who have both visited Hospital 1 and Hospital 2. They have the following medical record numbers:
Simply searching for the patient with record number "12345" would cause confusion.
The system string is our guiding light here. It allows us to clarify which identifier comes from each hosptial.
Now if we add the system string to our search, we can do a targeted query for Bob.
See our search guide for more information about searching with
Healthcare thrives on codes. Labs, medications, billing - they all have alphanumeric code systems. These standardized codes help healthcare actors communicate, reduce ambiguity, and streamline interoperability. You may have heard of some of these codes, like CPT for "procedure codes" or ICD-10 "diagnosis codes".
In an ideal world, there would be one universal code system for any application. But real-life healthcare is more complicated.
Let's take medications as an example. There are at least four common coding systems used to identify medications (for a deeper dive, check out our guide on medication codes).
This is where
CodeableConcepts come in handy. They anticipate that the same concept (e.g. drug) might have different representations (aka codes) in different systems.
text: 'Tylenol 325 MG Oral Tablet';
However, not all
CodeableConcepts map to a standard system. For example, assume that you are using the
Communcation.category field to organize messages based on product lines. Since product lines are specific to your company, there won't be a standard code system available. In these cases, you will develop in-house, or local , codes.
Best Practices for System Strings
Identifiers, the strategy is simple: each system string should correspond 1:1 with the source system. For instance, a patient ID from a particular hospital should have a system string like https://hospitalname.org/patientId.
When it comes to
CodeableConcepts, it gets a bit more complex. Whenever possible, you should use standardized code systems to avoid reinventing the wheel and promote good data hygeine. The FHIR community has defined standard
system strings for these code systems.
Some commonly used code systems:
|Procedure Names. Provider roles.
For local codes, **the system string should reflect the degree of consensus **you want to enforce across your organization.
A system string like https://my-healthcare-company.org/productLine could indicate a company-wide standard for product lines, while https://my-healthcare-company.org/messaging/productLine could refer to a standard specific only used within the messaging function.
System strings are your go-to tool for successful healthcare data management. By keeping them clean and consistent, you'll save yourself a lot of confusion and time.