NIH/NEI FHIR for Research Webinar

In the first part of this webinar, we will introduce FHIR for Research, and in the second part we will get into deeper technical detail.

We'll start off by talking about the FHIR standard at a high level. FHIR is a standard for exchanging health information electronically. Standards like FHIR help to establish a common language and a common process for health information technology systems which allow these systems to communicate with each other and share information more seamlessly and efficiently.

FHIR stands for Fast Healthcare Interoperability Resources. The "Fast" refers to designing and implementing FHIR. One of the design goals of FHIR was to specifically to make FHIR easier to work with from an implementation standpoint compared with other standards in use at the time.

"Resources" refers to building blocks of FHIR, and we'll be talking a lot about resources in the rest of this webinar.

FHIR is an open source standard that is free to use. It is developed as part of an open standards process.

FHIR is modular: resources and other constructs in FHIR allow for solutions to be assembled to meet the needs of a specific use case.

This kind of customizability is built-in throughout FHIR's design, including through FHIR features like extensions and profiling. We'll talk more about those features later on in the webinar.

FHIR is currently used in the real world. We'll talk about some research applications of FHIR later on in the webinar. In addition to these, FHIR is currently used for some very widely used patient-facing applications, like getting data from EHRs into the Apple Health app on iPhones, and in the digital vaccine record barcodes that are used throughout the US.

FHIR is also used actively in clinical settings, often as a way to integrate a third-party application or workflow into an Electronic Health Record or EHR. An example of this is Health Dart, which pulls relevant outside medical records for emergency medicine patients directly into an EHR workflow without needing to switch to a separate system.

Using FHIR may be the best path to getting new AI/ML applications integrated into clinical workflows as well, without having to wait for the IT vendors to deploy these applications as first-party features in their software.

To give you a sense of what kinds of resources are available in FHIR, this screenshot shows a partial list of the FHIR resources available in the most recent published version of FHIR called FHIR R5.

The take-away from this slide is that there are a lot of different resources covering a wide variety of health-related data types.

Resources related to diagnostics, like Observation and ImagingStudy might be expected. There are other resources related to healthcare workflows like Schedule, Appointment, and Encounter. There are also a number of resources that are used to implement FHIR features, like StructureDefinition and ValueSet.

If you're interested seeing the full list of FHIR R5 Resources, you can go to https://hl7.org/fhir/r5/resourcelist.html.

Now that we've talked about the kinds of data FHIR can represent, we'll talk about how these data can be moved around using FHIR. This slide shows a diagram of a standard FHIR information flow.

Typically, when systems use FHIR, there is a FHIR client (over the left). It could be an app, it could be a user interface on a computer, or it could be a backend server.

These clients can then request FHIR information from a FHIR web server.

Those requests go over the HTTP RESTful API. This is common web technology -- it's not just something that's used by FHIR. We'll talk a little bit more about how FHIR leverages common web technology, both for the RESTful interface and also for other aspects of FHIR.

The FHIR web server could be part of an EHR or it could be a standalone server, and the FHIR web server can communicate with underlying data systems that store the data, and then convert those data into FHIR format to send back to the FHIR client.

An example of a FHIR client is the the health app on an iPhone that uses FHIR to connect to a patient's providers EHR to pull down data. It can also be a research application. It could be something like a clinical decision support system that gets integrated into an EHR. And all of these use the same underlying approach for asking for data from the FHIR server and for for formatting that data for sending back and forth.

Now that I've introduced what FHIR is and how it works at a high level, I'll talk a little bit now about where FHIR came from.

You might have heard of HL7 V2 or HL7 V3. HL7 is a health standards body. They're responsible for developing FHIR and for maintaining FHIR and also for some of the other key health IT standards that are used both in the US and also internationally.

V2 is around 30 years old now and it was designed for point-to-point messaging. It was limited to messaging like orders and transfers and couldn't handle complex interoperability like we'll talk about with FHIR, like connecting custom clinical decision support systems directly into an EHR.

HL7 V3 was developed to to provide a replacement for V2 that was more flexible and addressed some of the other issues with interoperability around V2. However, in practice V3 was pretty hard to implement, so it isn't widely used except for one exception that I'll touch on a little bit later.

FHIR came out of these standards. It really tried to take the lessons learned from these standards and develop a new standard that was easier to implement, easier to use, while using technology that was already widespread in the general tech industry -- not just in health care technology. So later on in the webinar, we'll talk about how common technologies like JSON and XML are used to format FHIR data rather than a healthcare domain-specific format. I've already mentioned the RESTful interface that goes over an HTTP connection -- this is the same technology we use for accessing web pages. FHIR implementations also use OAuth2 and OpenID Connect, which are common authentication and authorization standards that are also widely used for web applications outside of healthcare.

To put the timeline of FHIR into a little bit of perspective here, FHIR was first introduced in a blog post on Grahame Greaves blog. He's the main architect of FHIR at HL7. This was back in 2011. And since then there's been a regular cadence of updates to the FHIR specification. The most recent version of FHIR (called FHIR R5) was released in December 2023.

And I've highlighted the word normative here on the slide. Normative means that the resources with this flag attached to them are considered mature enough to not really need any more changes going forward. And this is just a signal for the level of maturity. It is one of the reasons why now is a good time to start looking at how FHIR can be used for research, because it really is getting to that point where the at least some of the key parts of the specification are quite mature and also seeing adoption.

You'll notice the "Eyes on FHIR IG" on the timeline. This is an ocular-specific FHIR specification that was developed in 2021 and 2022, which we'll talk more about later in the webinar. I want to mention it now because it helps to frame the maturity of FHIR's use for eye-specific applications -- these are not as mature as other specifications in the FHIR ecosystem. One of the goals of having this webinar is to catalyze more work around FHIR for eye research to lead to greater maturity and adoption.

We'll come back to FHIR adoption in a bit, but first I want to talk about some examples of how FHIR can be used specifically for ocular research.

This isn't meant to be a comprehensive overview of all the ways that FHIR could possibly be used -- instead, it's a collection of some of the more relevant use cases based on what we've learned from talking to ocular informatics experts and what's been published across other specialties.

We will go through each of these use cases on the next few slides:

1. Clinical decision support (including custom AI)

2. Interoperability between ocular imaging devices and EHRs

3. Integrate non-standard data into EHRs (e.g. patient-reported)

4. Clinical trial case report forms

With clinical decision support, FHIR provides a standard format and structure for working with data from an EHR, as well as a way to standardize on terminology.

A related technology called SMART on FHIR provides a way to integrate a custom web application into an EHR, which allows you to integrate non-FHIR data into a CDS workflow, including output from an AI or ML model.

There are two citations that are relevant here, which we'll cover on the subsequent slides:

• https://doi.org/10.1016/j.ogla.2020.08.006
• https://doi.org/10.1055/s-0041-1728757

This paper explains how SMART on FHIR could be used in a glaucoma clinic. If you're interested in research on new ocular-related CDS approaches or workflows, this paper is worth reading.

We weren't able to find any examples in the literature of eye-specific CDS powered by FHIR, but there are some good examples from other specialties. This paper in particular is a good example of integrating an AI model for predicting likelihood of success for alternate treatment strategies for Type 2 diabetes into a EHR, in this case at the University of Utah.

This is a a screenshot of one of the figures from the paper showing what the interface actually looks like inside the EHR. What's interesting about this is that with SMART on FHIR, the authors were able to get data from the EHR for the specific patient sent out to the AI model. The AI model was able to deliver these recommendations customized for that specific patient, and then this was able to be directly integrated into the EHR.

One of the things we heard from the researchers we talk to was that getting data from ocular imaging devices can be difficult, and FHIR provides a mechanism that can support data exchange between the EHR and a PACS used by these devices.

Like with CDS, for this use case FHIR provides a data format, a structure, and a way to standardize terminology. FHIR API endpoints or SMART on FHIR can be used to move data in or out of the EHR.

We were not able to find any journal articles talking about using FHIR to connect EHRs and ocular imaging devices, but there was a FHIR Connectathon back in May of 2021 that had a track specifically around this particular use case, and this link provides some more information about how that worked if you are interested in reading more. This article has more detail about an image-centric workflow using FHIR that may also be of interest.

A third example of using of FHIR that may be relevant for ocular research is integrating patient reported data into an EHR. We didn't find an ocular-specific example of this, but we do have this example related to COVID-19 symptoms self tracking. The authors of this paper integrated this patient-reported data form into Yale's EHR using SMART on FHIR. They were able to successfully record patient reported data like oxygen saturation into the EHR, and this paper has a really good discussion of the IT challenges and solutions that they found.

Another use case is using FHIR to fill in repetitive forms with data from an EHR, like clinical trial case report forms in this example. Usually in a clinical trial, these forms would be filled out manually by a study coordinator. This paper is a proof of concept looking at 40 patients in a COVID trial at Vanderbilt, using EHR data to fill the case report forms using FHIR.

The there is a total of almost 12,000 values that could be populated with FHIR in this paper. 84% of those values were able to be populated with data from the EHR using FHIR, and they had 89% concordance with human data entry; the few mismatches were actually often due to the data entry error.

The study flow diagram on the right hand half of the slide is Figure 1 from the paper. It shows just for the first ten participants in the trial, a breakdown of what happened with the matching of these data elements. So for those first ten patients, 93% were exact matches. For the fields that were mismatched, 6% were due to coordinator error (i.e., human data entry error). Just a few were due to issues with the underlying EHR data.

Again, this is not an ocular-specific example but it shows how FHIR can be leveraged if you need data from an EHR for something like case report forms.

Note that the papers in the previous slides, and all the links in this presentation are available at https://purl.org/fhir-for-research/nei/webinar for reference.

Next, I'll talk a little bit about the current state of FHIR adoption. This map shows FHIR adoption as of 2019. Unfortunately, there is not a more up to date map available. But in 2019 this shows that 87% of hospitals and 69% of these clinicians use EHRs that were certified for HL7 FHIR.

We have some more recent data that shows that around 78% of clinicians now have also EHR software that supports FHIR and the five leading EHR vendors includes support for FHIR and these cover 55% of all clinicians.

FHIR is now it is quite widely available and especially most large health systems are running the EHRs that support FHIR.

There are a couple of factors that are driving FHIR adoption.

One is the 21st Century Cures Act. The Office of the National Coordinator for Health Information Technology, or ONC is responsible for implementing the US Health IT certification program alongside the 21st Century Cures Act.

The Cures Act supports better access to health information and has added in some additional interoperability criteria into the existing Health IT certification program. This Health IT certification program is voluntary for health IT vendors, but CMS provides a financial incentive, which means that it is pretty widely adopted.

Some of the key milestones for adoption of FHIR as part of ONC rules include:

• USCDI in 2021 (see next slide)
• FHIR APIs at the end of 2022
• FHIR Bulk Data Export at the end of 2023, which provides a way to get large amounts of FHIR data for background processing

USCDI is a standardized set of data elements for health data in the United States. US Core is the FHIR implementation aligned to USCDI. The first published version of the US Core specification initially came out in 2021, and it's been updated every January since then, starting in 2022.

A lot of other US-focused FHIR specifications are actually based off of US Core. And this is helpful for researchers because if you are working on a specification or you're using an existing one, and it's already based on US Core, it makes it a lot easier for an EHR vendor to actually implement it.

No ocular data is currently in USCDI, but NEI is actively working on addressing this. For more information see: Baxter, et al. (2022) Ocular Health and National Data Standards: A Case for Including Visual Acuity in the United States Core Data for Interoperability (USCDI). Ophthalmology Science. https://doi.org/10.1016/j.xops.2022.100210.

I'll now discuss FHIR's relationship to other standards.

I previously mentioned HL7 V2 and V3 as other standards that are related to FHIR. I'll cover these here in a bit more detail as they're still definitely in use and relevant.

As I said before, HL7 V2 is around 30 years old. It allows for simple transfer of information, or point-to-point messaging -- it doesn't support more complex interactions. So for example, the paper that used SMART on FHIR to add custom clinical decision support directly into an EHR would not really be possible using V2, but it is possible with FHIR.

HL7 V3 was developed as a way to extend interoperability from V2 to allow for a lot more complexity. It also used some standard technologies like SOAP and XML that come from outside health IT and the idea of V3 was to allow for a lot more flexibility. Unfortunately, this additional flexibility also ended up with a lot of complexity for implementation. So V3 was not widely implemented in the same way that V2 was, but V3 did lead to Clinical Document Architecture or CDA, and that standard for clinical documents is more wisely implemented.

And then finally, FHIR, like I said before, is based off of some of the lessons learned from V2 and V3.

One of these lessons learned is using current web technology as much as possible, which is really useful for for implementation. This means software developers don't necessarily have to have deep health IT experience or specific experience with FHIR in order to pretty quickly get up to speed and be productive working with FHIR -- this is really useful for developing custom applications: it makes it a lot easier to find people who can work on those applications, and it makes development of those applications more rapid because it uses standard technology that's already baked into a lot of the software development tools that software engineers use outside the health domain.

One of the questions that comes up a lot is how FHIR works with other common data models for research. OMOP is an example of one of these common data models that is pretty widely used in the research world.

OMOP is a common database structure that uses the OHDSI common vocabulary to provide standardized representation of observational data.

In March 2021, HL7 and OHDSI announced they were collaborating on interoperability for research.

As part of this collaboration, one of the Vulcan FHIR Accelerator's projects is a OMOP to FHIR Implementation Guide.

FHIR Accelerators are a key part of the HL7 community that drives development and adoption of FHIR standards. There are a number of active Accelerators in addition to Vulcan.

Vulcan's goal is to:

...close gap between clinical care and clinical research to improve patient lives, decrease costs and improve efficiency.

FHIR Implementation Guides or "IGs" are the written specifications that define a "set of rules of how a particular interoperability or standards problem is solved." US Core is also a FHIR IG, and we'll talk more about IGs throughout the rest of this webinar.

The OMOP to FHIR Implementation Guide explains:

FHIR’s role in a research data ecosystem is provision of a platform capable of supporting lossless exchange of data, knowledge and other health artifacts via its numerous FHIR resources and compliant APIs.

In contrast, the OMOP Common Data Model was designed to store observational data optimized for research analytics and for utilization by the OHDSI community using OMOP-compliant tools to generate novel research methods and discoveries improving health.

...

A stable set of transformations between FHIR and OMOP permit broader utilization of observational data in research systems, enabling FHIR API access to OMOP databases and data on FHIR servers to populate OMOP instances.

In other words, FHIR can facilitate loading data into OMOP, and work is being done to allow access to OMOP data using FHIR APIs.

FHIR is also useful for use cases that don't really make sense for OMOP, like getting real-time data about a specific patient from an EHR, integrating directly into an EHR-centric workflow, or sending data into an EHR from an external source.

NEI is helping to get better support for eye-related data in OHDSI through the Eye Care & Vision Workgroup.

From https://www.ohdsi.org/wp-content/uploads/2023/10/510-HribarBriefreport.pdf:

The OHDSI Eye Care and Vision Research Workgroup was formed to advance development and implementation of data standards in eye care research that will support studies using observational data for generating evidence to improve vision outcomes.

This includes adding eye-related concepts to medical terminologies like SNOMED and LOINC.

See also: Cai, et al. Advancing Toward a Common Data Model in Ophthalmology: Gap Analysis of General Eye Examination Concepts to Standard Observational Medical Outcomes Partnership (OMOP) Concepts. Ophthalmology Science 2023;3:100391. https://doi.org/10.1016/j.xops.2023.100391.

The Eyes on FHIR IG was developed in 2021 and 2022, and support for some aspects of eye-related data. This was the IG used in the May 2021 FHIR Connectation that I mentioned previously.

• FHIR® is an open standard for exchanging health data that is widely adopted and has untapped potential to enable/accelerate research.
• FHIR® may be useful for research touching EHR data. Examples:
  • EHR integration with custom clinical decision support (including imaging, AI/ML, etc.)
  • Interoperability between EHRs and ocular imaging devices
  • Integrate patient-reported data into EHR
  • Clinical trial case report forms
• FHIR® is increasingly widely available due to ONC’s Health IT Certification program and community-driven efforts like FHIR Accelerators
• FHIR® peacefully coexists with research CDMs like OMOP
• NEI is actively working on advancing representation of ocular data in standards like FHIR and OMOP
• More information: https://purl.org/fhir-for-research/nei/webinar

Using standardized terminology is really important for all health information technology, including research applications. This allows researchers to exchange and organize health data in a consistent and reliable way.

For example, if a standardized terminology is used to identify conditions in a problem list, then something like automated cohort building software can build a cohort based on the presence and absence of these conditions. If you don't have standardized terminology, you're relying on something like trying to parse plain text descriptions of conditions, which is much less reliable.

Some of the common kinds of terminology or code systems that are typically encountered in the FHIR world are LOINC for identifying laboratory tests and SNOMED CT, which is a really broad health terminology system. Some of the applications for SNOMED include identifying the results of laboratory tests, but it also has lots of other things in it, like diseases and diagnoses. ICD-10 is another example of a very common terminology. RxNorm for identifying medications is another example.

FHIR supports working with terminologies in a few different ways. FHIR supports defining code systems for use cases where you need to define a custom code system rather than using a standard one like SNOMED CT. You can also map between different code systems with FHIR, like mapping SNOMED CT onto ICD-10 for example. FHIR also allows the binding of a specific data element onto a specific subset of concepts from selected code systems.

Goldstein, et al. Visual Acuity: Assessment of Data Quality and Usability in an Electronic Health Record System. Ophthalmology Science 2023;3:100215. https://doi.org/10.1016/j.xops.2022.100215.

This paper discusses the challenges with abstracting visual acuity data from an EHR, and shows that about 24% of visual acuity data in their sample required post-processing for standardization against their data dictionary or could not be mapped to a data dictionary at all.

If it's possible to define a discrete data dictionary for a data element like this, FHIR provides a standardized approach to define the data dictionary and machine-readable version of the data dictionary that can be used for automatic validation of entered data. FHIR also provides other mechanisms to define constraints around non-discrete data elements. These can all be defined in a FHIR IG.

This shows an example of the Patient resource in FHIR R5. Recall that FHIR resources are the building blocks used to represent data in FHIR format.

You can see at the top of the screenshot the definition for the Resource, in this case:

Information about an individual or animal receiving health care services

Under this root element (Patient), there are a list of the data elements that are part of the FHIR Resource. FHIR Resources typically don't require that the contained data elements are filled in and you can see this with the 0.. for the "cardinality" of all the data elements in the screenshot. This means that the minimum number required values for each of these elements is 0, meaning that they are optional by default.

Often a specific use case will require that a data element is always populated. For example, many use cases will require Patient.identifier to be populated

I want to focus now on the Patient.maritalStatus data element with the arrow on the slide. We can see on the the right side here that this element is is bound to a "Marital Status Codes" value set with an extensible binding.

If you clicked the hyperlink to the "Marital Status Codes" value set, you would see a list of machine-readable the codes in the value set (A, D, etc.) along with their human-readable versions (Annulled, Divorced, etc.) and their definitions. I've copied some of these onto this slide.

You also see that each code comes from a code system -- all the codes on the slide come from the http://terminology.hl7.org/CodeSystem/v3-MaritalStatus system. In this case, this is a HL7-specific code system for marital status, but for other data elements the code system could be ICD-10 or SNOMED CT.

If we looked at the full Marital Status Codes value set, we would see there is actually a code from a 2nd code system in this value set: this is the unknown code UNK, which comes from the null flavor code system (https://www.hl7.org/fhir/R5/valueset-marital-status.html). This is another HL7-specific code system.

Value sets can include codes from different code systems if needed, which is important flexibility for some use cases.

Like I said before, the Patient.maritalStatus data element is bound to this value set, meaning there is some degree of requirement that a patient represented by this FHIR resource would define marital status using one of these codes.

Note that I said "some degree" -- whether the value for marital status has to come from this value set or just should come from the value set depends on the "binding strength."

In this example, the binding strength is "extensible". This means that if a code in the bound value set represents the concept in question, then that code must be used. Otherwise, a different code can be used. So the concept "divorced" would have to be represented with the D code, but a different marital status that isn't included in the HL7 value set could be represented by an arbitrary code from an arbitrary code system. Note that the code system is always included in FHIR data along with the code, so if a different code system was used for this, there is a path to looking up the code system if you saw it in FHIR data.

Other binding strengths include "required," "preferred," and "example." The definitions of these binding strengths are at https://www.hl7.org/fhir/terminologies.html#strength. The different binding strengths allow an implementer to create a profile of patient resource that could have a more strictly defined set of rules around how marital status is to be represented. For example, if for a research study, you need to know marital status and it needs to be a specific set of codes based off of the data dictionary for the for the study, you can do that. If you have a FHIR implementation guide, you can create a value set that has just those codes in it, and you can bind it to the marital status data element with a "required" binding strength

There are automated tools available that allow you to take FHIR data and verify that it actually conforms to the constraints defined in a FHIR IG -- for example, to make sure that it doesn't have any values for marital status that aren't expected. If you've created an implementation guide and go through this process, you have a clear way to make sure that the data you're getting are already cleaned and match what you expect. This makes it a lot easier to work with the data for analysis.

To quickly review the implications for research for terminology in FHIR:

• The FHIR specification describes where a data element like marital status should be stored: in this case, it's in the Patient resource and it's in a field called Patient.maritalStatus.
• The FHIR specification also describes how marital status is encoded. In this case, it uses a terminology binding with a preference for the specific set of codes that we just talked about in the Marital Status Codes value set.
• If you need to further restrict this, you can with a FHIR Profile.
• If you need to specify a specific set of codes valid for a given use case or study, you can do that too, by creating your own value set. You can pull codes from multiple different code systems into this value set to get exactly the set of codes that you need.
• You can use FHIR to represent translations between different code systems. There's a FHIR resource called a ConceptMap that's designed specifically for this and that allows you to relatively easily describe in a computable way the mappings between two different code systems. This may be useful if you need to include data from multiple systems that represent the same concepts in different ways.
• It's typically best practice to use codes from an existing code system like SNOMED CT or LOINC whenever possible. It's also possible to get new codes added to these code systems, like the OHDSI Eye Care & Vision Workgroup has done.

I'll now talk a little bit more about FHIR resources and profiles.

As I mentioned in the first part of the webinar, resources are the building blocks of FHIR. They act as customizable templates within the general FHIR framework and can be put together to solve a specific problem or meet a specific use case.

There are 157 FHIR Resources in the R5 release of FHIR, including resources like Patient, which we've already seen. Other examples include DiagnosticReport, Practitioner and Location -- and there are many more.

The resources in the base FHIR specification are designed to be very flexible. So for example, you won't see a lot of required value set bindings in the base FHIR specification. I'm actually not aware of any required bindings in the base FHIR resources because required binding really limits what the resource can be used for: if you have a use case that that needs to use a different value set you just wouldn't be able to use that FHIR resource.

The take-away here is that the FHIR specification tries to be as flexible as possible to avoid this kind of problem. Almost every data element in the base FHIR specification is optional, even information that may be critical for common health IT use cases. For example, in an EHR, having a patient's name and date of birth and address are pretty critical, but FHIR doesn't require that those are filled in. Instead, adding in these constraints is done downstream with use case specific FHIR Implementation Guides.

FHIR resources without an Implementation Guide are not actually that useful for many use cases because there is so much flexibility that standardization is hard. To have that standardization, you need a FHIR Implementation Guide that contains FHIR Profiles that add constraints and add extensions to supplement the base FHIR resources. This is how you're able to really customize FHIR to meet your your specific needs.

Profiles in an Implementation Guide define which resources should be used for a given use case like for research in a specific clinical domain. Profiles also define which data elements should be populated, and how the data elements should be populated for that use case.

If there are concepts that don't map onto data elements in FHIR resources, it's also possible to add your own data elements through a feature called "extensions", but this should only be done if necessary because it makes interoperability more difficult.

I showed in the first part of the webinar a screenshot of part of the list of the 157 Resources in FHIR R5. Some examples of FHIR resources include administrative resources like Patient and Practitioner; Organization, which could be something like a hospital; and Location. (Location is useful if you want to describe an Organization with multiple physical locations, like a pharmacy chain.) There are also resources related payments, meaning that coverage for insurance and claims can also be represented with FHIR resources. There are a number of clinical-related resources for things like AllergyIntolerance, Condition, FamilyMemberHistory, and CarePlan.

There are also a number of resources related to FHIR itself, like StructureDefinition, which is how FHIR Profiles are defined. Composition resources allow you to bring together a number of FHIR resources to essentially tell a clinical story. CapabilityStatement is a FHIR resource that's used to describe the capabilities of a FHIR server. If you'd like to read more about the different types of resources, the best place to go is the FHIR R5 specification.

Part of the design challenge for the FHIR Specification is figuring out what should be a resource -- what has the right scope that isn't too broad or too specific to make sense. The list of "non-examples" here illustrate this:

• Patient name is too small to be a resource. Instead it's implemented as a handful of data elements inside the Patient resource. There would be way more than 157 resources if concepts like "patient name" had their own resource, and it would make the specification unmanageable.
• Electronic health record is too big to be a resource -- there would be thousands of data elements and things like longitudinal data would be really difficult. Instead, with FHIR, you could represent an EHR as a collection of a whole bunch of different FHIR resources.
• Blood pressure is too specific to be its own resource. It makes more sense to generalize this and use an Observation resource to represent blood pressure. Observation can represent lots of other observations about patients too.
• Intervention is too broad because this might include multiple medications or procedures, and it's better to use something like the Composition and Bundle resources to bring together multiple resources that represent an intervention.

Profiles are how FHIR resources are customized for a specific use case.

Resources like the ones we saw on the prior slide are the building blocks of the FHIR specification. They define how data is structured and exchanged, and are designed to be generic enough that they can be used in a wide variety of use cases.

Profiles adjust resources for a specific use case. This is done in two ways:

1. Restricting, or adding constraints, like requiring that a specific data element is populated, or a certain ValueSet must be used
2. Extending, like adding new custom data elements with Extensions

Profiles are typically published in an Implementation Guide for sharing with implementers.

Interestingly, the way you create profiles is with a resource called a StructureDefinition -- so you actually use FHIR itself to create customization.

To show you an example of what a FHIR Profile looks like, I'm going to show you some screenshots from US Core's profile of the Patient resource.

This page is on the US Core IG's website, and when you open it, the top has some narrative about the purpose of the Patient profile and guidance on implementation.

If you scroll down, you'll see this table, which is generated from the StructureDefinition resource that computably defines this profile. This kind of table appears in all FHIR profiles, and a similar table is used in the base FHIR specification for defining resources.

I'm going to zoom in on the contents of the table to try to make it a little easier to read.

The first row of this table shows the FHIR Resource that is being profiled. In this case, we can see it's Patient, and we could click the link under "type" to view the Patient resource in the FHIR specification.

After that first row, each row represents a data element that is being somehow modified by the profile. (There's a different view of this table on the web page that shows all the data elements regardless of whether or not they are modified by the profile.)

The left-most column provides the name of the data element, like race. If you click on the name of an element, you will jump to a more detailed description of the element.

The other cells in that row provide more information on that particular data element.

• Flags provides information for implementers on how to handle the data element. For example, the C flag indicates there are additional constraints defined on that element that need to be considered by an implementer. The S flag indicates the element is "MustSupport", which sets expectations for when an element should be populated if the applicable data are available in the underlying system.
• Card. stands for cardinality, and it provides a range for how many values need to be populated for that element. 0..1 means that the element can either be left empty or given one value. 1..* means that the element has to have at least one value, and can have more.
• Type is the data type of the element in question. The FHIR Specification provides a number of data element types. These can be things like "string" for text or "boolean" for true/false values. In this case, (Complex) indicates an extension: the concept of race is not part of the Patient resource in FHIR by default, but to support USCDI it was necessary to add it in so this was done via an extension.
• Description & Constraints provides a short narrative description of the data element.

I want to talk about the name element for a minute because it's a good example of how FHIR can be used flexibly to meet some complex needs.

You can see the name element is required: it has a cardinality of 1..* meaning that at least one name must be provided. There is also a reference to instructions for what to do if a name in fact is not available: without this "escape hatch" for missing data, it would not be possible to use this profile in a conforming way if name wasn't available.

There are several sub-elements under name, like family, given, and suffix. Note that these are all 0.. cardinality: they are not required even though the parent element is required. This makes it possible to represent someone with just a single name, or provide partial name information when the complete name isn't available.

This kind of flexibility is really important for dealing with real-world health data because there can be so much heterogeneity. A lot of thought has to be given to this when creating FHIR specifications to handle this kind of thing to avoid major issues when trying to implement them.

You also notice the red S flags on family and given. These indicate these elements are "MustSupport", which I mentioned briefly before. This is a really important concept in FHIR implementations because it allows for specification authors to identify which elements are important for a given use case without making them required. If family and given were required, there would be a set of corner cases where the profile just wouldn't work.

The "MustSupport" flag's precise meaning depends on the use case and the role of the implementer. Generally it means that the systems that are implementing the profile need to have some way to meaningfully support the data element. This might mean populating the data element for a system generating FHIR data, or for a system that reads FHIR data, it might mean being able to read the data element and display it.

Here's an example of an extension in FHIR. This is US Core's Race extension, and you can get to this by clicking on the extension URL next to the race element on the US Core Patient profile.

You can see the root element type here is Extension, and it contains a few different custom data elements to represent race.

The first is the ombCategory, which has a required value set binding to the "OMB Race Categories" ValueSet. We'll look at this in more detail on the next slide. This data element provides a way for race to be represented in a standardized way from a set of 5 predefined codes from OMB. You notice the red S flag indicating this is MustSupport. The precise meaning of this depends on the implementer (more information), but the high level meaning is that this data element is expected to be used whenever possible for US Core implementers.

The detailed element also has a required binding to a different ValueSet, which has a much more extensive set of options that are more granular.

The text element is required and provides a string field for a text description of race.

The OMB Race Categories ValueSet.

This shows how the 5 categories OMB has selected for race are encoded -- each has a code like 1002-5 and a human-readable description like American Indian or Alaska Native.

Here's the race data extracted from an example Patient in US Core. You can see that the three relevant OMB categories for race for this patient are represented here, as well as two more detailed race codes, and the text value from the extension.

The data here are in JSON format, which is a commonly used way of structuring data exchanged between systems, especially systems that interact with web servers. We'll talk more about this in a few slides.

Before we get to that, I wanted to talk again about FHIR Implementation Guides, or "IGs" in a little more detail.

IGs are a collection of profiles, extensions, and value sets like the ones we just saw from the US Core IG. These are both human- and computer-readable. The human-readable portion is distributed as web page, which is what the screenshots I was showing you are from. IGs also typically have a lot of narrative content, as well as diagrams and other information to help implementers that are part of this web page.

The computer-readable version of the IG is in a format like JSON or XML, and can be downloaded through the IG's website.

IGs support specific use cases, and as I mentioned before they can both constrain and extend the FHIR specification to meet the needs of their use cases.

IGs can be published independently on the web, or created through a standards process like the ones created under HL7. There are 246 IGs currently registered with HL7, and even more that are published elsewhere.

HL7 has work groups that focus on a specific domain, like clinical quality or public health. You can work with one of these work groups to publish a FHIR IG related to that domain.

HL7 FHIR Accelerators are another avenue for FHIR IG development. I mentioned Vulcan before as an example of a FHIR Accelerator that's focused on research, but there are a number of other accelerators. mCODE is an example of a FHIR IG that comes from the CodeX FHIR accelerator -- this IG is focused on oncology-related use cases.

I mentioned before that there is an eye-specific IG that was under development in 2021 and 2022 under HL7. If you're curious about this, you can visit the draft version at https://build.fhir.org/ig/HL7/fhir-eyecare-ig/index.html. The left half of this slide is a screenshot of the IG web page, and the right half is a table from the IG that goes through the different use cases under development.

These include representing various ophthalmic clinical concepts in FHIR, interoperability with imaging systems, and exchanging data.

We'll now cover more on how data exchange with FHIR generally works.

Here's an example of an "instance" of a FHIR Patient resource. It's in JSON format, and it's too long to fit on the slide...

...so I'm going to move the bottom part into a 2nd column so you can see it.

I'll now label the sections of the JSON with the kinds of data they contain.

First, we have the metadata, which identifies which resource this is an instance of, and a computable identifier for the instance (patient1 in this case).

Then we have a human-readable summary of the instance.

Then we have an extension, which includes a URL (in very small font so it fits) that refers to the resource that defines the extension (like the US Core race extension we saw a few slides ago).

Finally, we have the standard data content for the patient resource: a medical record number, the patient's name, gender, date of birth, and a reference to their provider.

We have the same resource now in XML format. Like JSON, this is a standard format that is often used for transmitting data between systems. It's a little easier for humans to read and it fits on a slide better than JSON, but JSON is often easier to work with in software than XML.

FHIR resources can be represented in both JSON and XML without losing any data, and it's relatively easy to convert between JSON and XML formats.

I mentioned REST earlier in the webinar as another common web technology that's used by FHIR systems, and I'll go into a little bit more detail about it here.

If you recall back to the first part of the webinar on the slide that showed the FHIR client and the FHIR server, the FHIR client and the FHIR server communicate over REST.

This is the same technology that's used by web browsers and web servers. If you type in https://somedomain.com in your web browser, you're sending a RESTful request.

Web browsers use a GET request by default to read data off of a server. FHIR does the same thing but FHIR also allows for creating data or updating data or deleting data. And each of those operations has a HTTP verb as well: POST for creating, GET for retrieving, PUT for updating, and DELETE for deleting.

When you're requesting data from a RESTful server, you have to provide the URL for that server. This would be the URL to the FHIR endpoint that's part of an EHR, or it could be part of another server like a FHIR-enabled OMOP database.

When you make a REST request, you typically send some metadata in "HTTP headers". This is how you say which data type you want back: if you want JSON, you can request application/FHIR+JSON or application/XML if you want XML.

You can send additional information if needed in the body of the request. For example, if you were creating a new FHIR resource instance with a POST request, you would send the JSON or XML for that instance in the body of the request.

Here's a breakdown of what a sample REST request looks like to a FHIR server:

• The GET HTTP verb
• The URL for the FHIR server: http://hapi.fhir.org/baseR4/
• The endpoint for requesting a Patient resource instance: Patient/
• The id of the patient in question: 2679766

For the response we see the 200 HTTP status code, the content type of the data being returned, and then the JSON data for the FHIR instance requested -- this looks very similar to what we've seen on the previous slides. This example is short, but in the real world the JSON or XML that gets sent back from the server can be much longer.

The last technology I'll talk about here are the set of SMART technologies out of Boston Children's Hospital that are relevant to research, and that are now maintained as part of the HL7 standards process.

I've already mentioned SMART on FHIR a few times earlier in the webinar. SMART on FHIR uses common web technology called OAuth and OpenID Connect to provide authentication, and authorization for third party applications. I'll talk a little bit more about that on the next slide.

CDS Hooks are another related technology which allows for actions to occur when something happens inside the EHR. So for example, if a certain action happens inside the EHR, you can hook into that with a CDS Hook and then suggest a SMART on FHIR application or trigger some kind of other action based off of what's going on in the EHR. And this provides a mechanism for being able to trigger integration with things like a smart on FHIR application.

I mentioned FHIR Bulk Data back when discussing the Cures Act and at the end of 2022, the implementation of Bulk Data is part of EHR certification with ONC. Bulk Data provides a mechanism for getting large batches of FHIR data, like population level data out of a FHIR server. As we saw here, a lot of FHIR APIs are more focused on getting a specific patient or a specific subset of patients, and Bulk Data allows for just accessing a greater set of patients all at once. Typically this would be used in something like a back end process that's doing some kind of bulk processing of a FHIR formatted data.

I'll talk a bit more here about SMART on FHIR.

SMART on FHIR provides a way for applications developed by third parties to connect deeply into an EHR. And it assures adequate security to protect personal data. So, for example, if I log into the health app on my phone with my patient portal credentials that can authenticate with the patient portal and pull data using SMART on FHIR and it only gives me access to my own data. It doesn't give me access to other patients data.

SMART on FHIR is helpful because it decouples the data from the app builder. So rather than having to have all apps built by the IT vendor that makes the EHR, third party app developers can come in and get access to that EHR data in a standardized way. This is akin to how the app stores work on smartphones: back in the early days of the iPhone, only Apple could make apps. When the App Store appeared, it allowed 3rd parties to create apps that run on Apple's platform and can access data that's stored there given the proper permissions. SMART on FHIR at a high level is analogous to the APIs that enable 3rd party iPhone apps.

There's multiple ways that SMART on FHIR can integrate with an EHR, or can live outside an EHR and request data from the EHR when needed. So the example I just gave of logging in on my smartphone to get access to my own patient data, that's an example of a standalone app that's not integrated into the EHR at all. You can also have an EHR Launch approach, which is how the Type 2 diabetes decision support app integrated into University of Utah's EHR in the example we saw earlier.

There's also a mechanism for SMART on FHIR to to use to EHR Launch on the server side to get access to FHIR Bulk Data API endpoints.

In summary, SMART on FHIR enables using the EHR as a platform for different apps from different vendors. These apps are not necessarily limited to research. They can be used for lots of other things, and they can be patient-centric or provider-centric. In any case, the idea is that you can write a SMART on FHIR app once and then be able to run it across multiple EHRs without having to do a lot of modification of the underlying code.

SMART on FHIR is relevant for a number of use cases related to ocular research. For example, it provides a mechanism for bringing image data from a PACS into an EHR's interface, and potentially for integrating AI/ML algorithms into clinical workflows. If your AI model needs data from the EHR, SMART on FHIR provides a mechanism to authenticate and retrieve the data you need in FHIR format on demand.

In summary, in the second part of the webinar, we talked about the basic building blocks of FHIR and went through the Patient Resource in some detail.

We talked about the data elements that are defined by resources, how these data elements have names and types, and they could be bound to terminology.

We talked about implementation guides, how implementation guides can be used for extending FHIR to meet a specific use case. This can be done by adding constraints like required elements or specific terminology bindings, and also by adding extensions if the base FHIR specification doesn't provide the data element that you need.

We also talked about the standard web technology that FHIR uses and how this can facilitate interoperability and could potentially be used to facilitate research use cases as well.