A technical overview of using FHIR to ask for a second opinion

In our previous blog post, we described how a patient could benefit from FHIR when transferring documents and findings to a radiologist for a second opinion. Instead of USB sticks, CDs, and retyping data, systems talk directly to each other via standardized interfaces.

But how does all of this work in practice? In this blog post we dive into the technical side of the use case: which FHIR resources are involved, how the CH RAD-Order implementation guide and SDC (Structured Data Capture) come into play, and what a realistic implementation in primary systems can look like.

This is the second post in a series of blog posts about FHIR.

FHIR (Fast Healthcare Interoperability Resources) is a modern standard for exchanging healthcare data. It was designed based on the lessons learned from HL7 v2 and v3 and from the web community at large.

For me, the salient point of FHIR is as follows:

• It's just modern web tech: FHIR uses RESTful APIs over HTTP and represents data as JSON or XML – just like most modern web services. This makes integrating cloud services, mobile apps, and other telemedicine platforms a natural fit.Tooling doesn't have to be written from scratch: most of the technology and tooling from the web ecosystem can be reused.
• Resource-based model:   Instead of the huge monolithic messages used in HL7 v3, or the ad hoc and site-specific extensions often seen with HL7 v2, FHIR defines small, composable  resources  such as  Patient,  ServiceRequest,  DiagnosticReport,  ImagingStudy,  DocumentReference  and many more. Complex workflows are modeled as combinations of these resources and references between them.
• Designed for extensibility (the 80/20 rule): FHIR aims to cover about 80% of the global use cases in its core specification. The remaining 20% is intentionally left to  profiles  and  Implementation Guides (IGs)  that adapt FHIR to a specific country, region, or organization. As such, extensions and constraints are first class concepts in FHIR.

In this post, we’ll see how this plays out for our concrete second opinion scenario.

Let's rethread what happened to Mara in simplified terms.

Actors

• The patient (Mara) and her  EPD (Electronic Patient Dossier)
• The referring physician (Dr. Meier) and his practice management software
• A radiology practice with its radiology information system

Workflow

• Dr. Meier creates a radiology order for a second opinion and sends it to the radiology practice.
• The radiology practice retrieves the order and accompanying clinical information.
• The radiologist reviews the existing exam, writes a report, and uploads the results to the EPD.
• Dr. Meier’s system automatically receives and displays the results.

In this post, we focus on  the first step: how Dr. Meier’s primary system creates a second opinion order in a way that other systems – such as the radiology practice – can reliably understand and process.

The first technical step is to represent the order and the patient information needed for the second opinion. In other words: how does Dr. Meier tell the radiology practice that they need to provide a second opinion on an existing Xray, in a machine-readable way?

We start with the ServiceRequest resource, which captures the radiology order itself. Along the way we’ll touch on core FHIR concepts such as resources, references, profiles and implementation guides. Afterwards, we’ll see how CH RAD-Order and SDC add a structured questionnaire on top of this to capture all the details of the order.

ServiceRequest as a FHIR resource

A service request is a machine-readable way to say: “Please provide this service for this patient, for this reason.”

In our case: “Please provide a second opinion on Mara’s existing Xray of the right leg. The clinical question is: Can you confirm a stress fracture of the right tibia?”

This is represented as a  FHIR resource. Resources are at the heart of FHIR. It’s even in the name ! Fast Healthcare Interoperability Resources. They provide structured, machine-readable and well documented “building blocks” for clinical information – here, the information needed to place a radiology order (such as an Xray, CT or MRI) or a second opinion.

Even without knowing FHIR in detail, you can spot some key information:

• The  category  shows that this is a  second opinion  request (SecondOpinion).
• The  subject  and  requester  reference Mara and Dr. Meier.
• The  supportingInfo  field points to existing data that should be considered: the filled in order form (QuestionnaireResponse), the existing  ImagingStudy  (the Xray) and the previous  DiagnosticReport.

How did the practice management software know how to create this JSON? This is where Profile and Implementation Guides come into play

A profile can be thought of as a machine-readable template for a given FHIR resource type. It defines what elements are mandatory, optional or forbidden, what value sets and/or code systems must be used (more on that later), what extensions are allowed, etc.

Looking back at our JSON, we can see that it claims to follow (or in the jargon: “conform to”) the profile.

But a profile in a vacuum does not help; most of the time a profile is part of an Implementation Guide (IG). In our case, the implementation guide is "CH Rad-Order". It describes how to define a common, interoperable way to represent radiology orders (as a reminder, a second opinion request for imaging is also a radiology order) in the Swiss healthcare system.

If you look closer, CH RAD-Order itself does not exist in a vacuum. It builds on top of another Swiss guide:

• The  Order & Referral by Form (CH ORF)  implementation guide defines how forms for eReferrals and requests for information (such as diagnostic imaging results, lab results, discharge reports etc.) can be defined, deployed and used.
• CH ORF defines a CH ORF ServiceRequest  profile.
• CH RAD-Order then  refines  this CH ORF ServiceRequest for radiology specific needs (e.g. imaging region, body site, requested imaging modality).
• This layering is very similar to regular software development:

  • Most projects depend on existing libraries and frameworks instead of reinventing everything from scratch.
  • In the same way, CH RAD-Order stands on the shoulders of CH ORF, which stands on the international FHIR  ServiceRequest  definition.

So far, we have looked at the  order as a clinical resource, a ServiceRequest that says:

“Please provide a second opinion on this existing Xray for Mara, for this reason.”

That’s what downstream systems use for workflow, scheduling, and reporting.

But this raises a very practical question:

How does Dr. Meier actually enter all the information that ends up in the ServiceRequest?

One option would be to hardcode a custom radiology order form in every practice management system and every radiology information system. With  m  different primary systems and n different order forms, that leads to  m × n  separate implementations. Readers of this article that have some development background may experience a déjà vu. This is a pattern also found in code editors: with m different editors that all would ideally need to support n programming languages. The solution there is to  standardize the messaging  between editor and language server and implement it once per side. In software development, we have seen this in the Language Server Protocol for code editors ; that's why niche or purpose-built code editors can have intelligent code completion, jump to definition, etc. for "free", or Model Context Protocol for AI tooling (again, different tools can easily integrate AI from different vendors relatively easily).

FHIR offers exactly such a common protocol for  forms following the Structure Data Capture IG:

• A  Questionnaire  describes a form: which questions are asked, which answer types are allowed, how sections are structured, etc.
• A  QuestionnaireResponse  contains one concrete set of answers for one particular case.

CH RAD-Order uses these to describe the radiology order form itself (QuestionnaireRadiologyOrder) and the filled in answers that Dr. Meier submits. The added value for primary system vendors is that they only need a  generic  Questionnaire  renderer and answer sender; the second opinion scenario is then “just” another questionnaire following the same rules.

To recap:

• The form that Dr. Meier sees rendered on screen is described by the  QuestionnaireRadiologyOrder  from CH RAD-Order: a structured definition of all the questions that make up a radiology order form (clinical question, imaging region, caveats, etc.).
• When Dr. Meier fills in this form for Mara, the result is a QuestionnaireResponse: one set of answers for this specific case. This will be sent to the radiology practice.

Here I'd like to highlight a few points:

• requestedService.service  indicates that this is a  second opinion  request. The questionnaire is multi-usage: with a different code it could be used for other services (e.g. a “new imaging order”). And in that regard, this type is encoded as a ValueSet resource. You can think of them as basically enums with more powers, as we will see in the next point.
• You may notice that in requestedService.service, a system is defined with an URL. This tells us what reference data to use. It can be inside an IG (such as with the requestedService), but also defined outside of it, for instance with the imagingRegion. This is particularly handy if you want to use an external ontological system (such as LOINC, SNOMED-CT and in our case Radlex). Mapping a concept or object to a unique identifier is a common use case in the medical field. This has several advantages, including but not limited to:

  • reduces ambiguity, because a “fever” means different things: a general symptom, a diagnostic, a specific disease, etc.
  • semantic interoperability, as in: different systems can draw meaning from data to enable automated processing
  • have easier multilingual support and overall easier machine processing (including machine learning / AI).
• And thus, this idea is so important that a whole module is dedicated to it in in FHIR, called Terminology.

To summarize, ordering a second opinion is captured like this:

• Forms are defined once  as  Questionnaire resources in an implementation guide (here: CH RAD-Order, based on CH ORF and SDC).
• Primary systems (medical practice software) implement a generic Questionnaire engine. This engine would render forms, collect answers, and send them as QuestionnaireResponse. The implementation shape (web form, mobile app, AI assistant reading the question and collecting radiologist answers…) is not relevant as long as a QuestionnaireResponse is generated.
• A formal clinical order is sent alongside the questionnaire answers. For this example, we can assume that the ServiceRequest resource is created from the QuestionnaireResponse.
• Nationally agreed upon profiles and code systems  ensure that different vendors’ systems interpret the data in the same way.

In this post we focused on  the first step of Mara’s radiological journey: the formation of a clinical order for a radiologist’s practice. What have we learned?

• Fundamental concepts of FHIR such as Resources, Implementation Guides, Profiles and how they relate together
• How a radiology second opinion order can be modeled with FHIR
• How CH RAD-Order builds on CH ORF and the base  ServiceRequest
• How SDC,  Questionnaire  and  QuestionnaireResponse  provide a reusable way to implement forms