This page is part of the Smart App Launch Implementation Guide (v2.2.0-ballot: STU 2.2 Ballot 1) based on FHIR (HL7® FHIR® Standard) R4. The current version which supersedes this version is 2.1.0. For a full list of available versions, see the Directory of published versions

Patient-Access Brand Examples

The brands below are fabricated for the purpose of these examples.

Example 1: Lab with Locations Nationwide

Let’s begin by considering a national lab with many locations nationwide.

The configuration below establishes a single top-level Brand with a potentially long list of ExampleLabs addresses. In this configuration there’s a single Organization associated with a single portal and endpoint. The organization lists several aliases and addresses.

(An alternative choice for ExampleLabs would be to create an Organization for each state as a sub-brand with its own name, logo, and addresses. This is a decision that ExampleLabs can make based on how they want their brand to appear in patieint-facing apps.)

Based on this configuration, a patient app might display the following cards to a user:

The FHIR server’s .well-known/smart-configuration file would include a link like

"patientAccessBrands": "https://labs.example.com/branding.json"

And the hosted Patient Access Brands Bundle file would look like:

Raw JSON

Example 2: Regional Health System With Independently Branded Affiliates

Next, let’s look at a Regional health system (“ExampleHealth”) that has:

• Has locations in/around 12 cities
• Provides EHR for independent affiliates (distinctly branded sites like “ExampleHealth Physicians of Madison” or “ExampleHealth Community Hospital”)

The configuration below establishes a single Organiztion for ExampleHealth, with a single portal associated with two FHIR endpoints (one R2, one R4). There are also Organizations for the affiliated providers, each indicating a partOf relationship with ExampleHealth.

Based on this configuration, a patient app might display the following cards to a user:

Raw JSON

Example 3: Different EHRs for different sub-populations displayed in a unified card

Now let’s look at a more complex (but still surprisingly common) scenario where a care facility (“ExampleHospital”) has two patient portals offered by different EHR vendors and split by audience:

• EHR1: “Patient Gateway” for adult patients to help them connect with providers, manage appointments and refill prescriptions.
• EHR2: “Pediatrics”, a patient portal where parents can access their child’s information.

The configuration below establishes a single Organiztion for ExampleHospital, with a portal for pediatrics and a portal for adult care, each associated with a distinct endpoint.

Based on this configuration, a patient app might display the following cards to a user:

(Note: In practice, if ExampleHospital uses two different EHR vendors to host these different portals, it’s possible that each vendor might publish only “their” portion of the content in an endpoint list. This is why it’s important to populate Organization.identifier with consistent values, allowing apps to merge details from different publication sources into a single card for a streamlined selection UX. This guide recommends the use of normalized website URLs as common identifiers.)

Raw JSON

Example 4: Two co-equal brands (“Brand1” + “Brand2”)

Finally, let’s consider the scenario where a single patient portal is associated with two brands, neither one considered “primary”.

One possibility is simply to duplicate the Endpoints and Organizations and maintain entirely separate copies of their information, which apps can render into separate cards.

But if both organizations really do share an endpoint, the configuration below shows a more precise way to model the situation with one Endpoint and two Organizations that point to it.

Based on this configuration, a patient app might display the following cards to a user:

Raw JSON