Profile on Organization to communicate the branding associated with a Patient Access API endpoint.

• Extensions about the Brand
  • 0..* MS Logo
    • url is http://hl7.org/fhir/smart-app-launch/StructureDefinition/brand-logo
    • valueUrl SHOULD be optimized for display as a 1” square and formatted as SVG or 1024x1024 pixel PNG with transparent background. Logo should be be legible at small sizes (e.g., as small as 50x50 pixels). Tips to achieve this: if the logo contains both a brandmark and a wordmark, separate them and use just the brandmark. If the logo is predominantly horizontal, consider creating a vertically-oriented logo that is still recognizable when scaled to smaller sizes. Multiple logos may be supplied. The URL can be an absolute URL with the https:// schema, or a Data URL with the data: schema that directly embeds content.
  • 0..1 MS Logo use agreement
    • url is http://hl7.org/fhir/smart-app-launch/StructureDefinition/brand-logo-use-agreement-agreement.
    • valueUrl MAY include a link to terms for logo use by patient access apps.
  • 0..* Brand flags
    • url is http://hl7.org/fhir/smart-app-launch/StructureDefinition/brand-flags.
    • This flag is intended to help app developers understand and debug the organizational relationships that underpin published Brands. For example, a valueCode of hidden allows systems to designate Organizations as part of a hierarchy without necessarily being shown in a UX card or tile. Marking Brands hidden can also be used to associate many affiliated organizations with a parent Brand (e.g., each with its street address) without apps displaying redundant information to users.
• Extensions about the Brand’s Patient Access (“portal”). These extensions represent the “Patient Access Details” described in the conceptual model above. These extensions are “inheritable”, which means Brand entries in the Brand Bundle systems MAY be omit these extension whenever correct values are inferrable by following the entry’s “Patient access provided by” links (Organization.partOf).
  • 0..1 MS Patient access name (“portal name”) Note: A Brand MUST include a this extension or inherit the value from the Brand referenced by Organization.partOf.
    • url is http://hl7.org/fhir/smart-app-launch/StructureDefinition/patient-access-name.
    • valueString indicates the name by which patients know the portal (e.g.,”MyChildren” or “Patient Gateway”)
  • 0..1 MS Patient access URL (“portal URL”) Note: A Brand MUST include a this extension or inherit the value from the Brand referenced by Organization.partOf.
    • url is http://hl7.org/fhir/smart-app-launch/StructureDefinition/patient-access-url.
    • valueUrl indicates the location of the patient portal associated with this Brand – i.e., a URL where patients can go to see their data and manage access.
  • 0..1 MS Patient access description (“portal description”)
    • url is http://hl7.org/fhir/smart-app-launch/StructureDefinition/patient-access-description.
    • valueMarkdown explains, if necessary (in patient-friendly language), the subset of patients eligible to connect and the data available. This capability supports (for example) a cancer center that uses one EHR for pediatric patients and another for adult patients. In this scenario, each EHR would publish a different PatientAccessBrand; apps would display the description to disambiguate the user’s selection. For instance, one Brand might indicate “Access records for childhood cancer care” and another might indicate “Access records for adult cancer care”.
  • 0..* MS Patient access logo (“portal logo”). Used if the portal has its own logo in addition to the Brand’s logo
    • url is http://hl7.org/fhir/smart-app-launch/StructureDefinition/patient-access-logo
    • valueUrl See documentation for “brand logo”
  • 0..1 MS Patient access logo use agreement
    • url is http://hl7.org/fhir/smart-app-launch/StructureDefinition/patient-access-logo-use-agreement.
    • valueUrl See documentation for “brand logo use agreement”.
• Extensions about customer-managed Brands
  • 0..* MS Logo
    • url is http://hl7.org/fhir/smart-app-launch/StructureDefinition/brands-bundle
    • valueUrl for a customer-managed Patient Access Brands Bundle that defines this Brand and related Brands. It allows customers to self-publish additional information about the Brand.
• 0..* MS identifier(s) that apps can use to link this Brand across publishers or with external data sets. EHRs SHALL support customer-supplied identifiers (system and value).
  • It is RECOMMENDED that each Brand include an identifier where system is urn:ietf:rfc: 3986 (meaning the identifier is a URL) and value is the HTTPS URL for the Brand’s primary web presence, omitting any “www.” prefix from the domain and omitting any path component. For example, since the main web presence of Boston Children’s Hospital is https: //www.childrenshospital.org/, a recommended identifier would be:

  { "system": "urn:ietf:rfc:3986", "value": "https://childrenshospital.org" }

• 0..* type Categories for this organization (system: http://hl7.org/fhir/smart-app-launch/CodeSystem/patient-access-category, code from: clinical, lab, pharmacy, insurer, network, aggregator)
• 1..1 MS name Primary brand name to display on a card
• 0..* MS alias Aliases (e.g., former names like “Partners Healthcare”) for filtering/search
• 1..1 MS telecom with system of url and value conveying the primary public website for the Brand. Note this is distinct from the patient access portal website (described below)
• 0..* MS address Locations (e.g., zip codes and/or street addresses) associated with the Brand. The following combinations are allowed:
  • State
  • City, state
  • City, state, zip code
  • Street address, city, state, zip code
  • zip code alone
• 0..1 MS partOf “Patient access provided by”, to convey that an affiliated Brand hosts this Brand’s API technology and patient portal. The hierarchy of “access provided by” links SHALL NOT exceed a depth of two (i.e., a Brand either includes portal details or links directly to a Brand that provides them).
• 0..* MS endpoint references one or more PatientAccessEndpoints. Typically, this property associates a single “primary brand” with the endpoint. Additional affiliated Brands or parent brands can be associated via “Patient access provided by” links (Organization.partOf). EHR vendors SHALL support integrated publication of Organizations in the same JSON Bundle, as well as external customer-managed publications:
  • 0..1 MS reference containing a relative URL to an Endpoint within a Brand Bundle

JSON FHIR Bundle (type: collection) of Endpoint and related resources is hosted at a stable, publicly available, publicly disclosed location. Bundle Entries include:

• Patient Access Endpoint Profile resources.
• Patient Access Brand (Organization) resources. Vendors SHALL publish at least a “primary brand” for each endpoint and SHOULD support the publication of a more detailed Brand hierarchy.

Brand Bundles SHALL populate Bundle.meta.lastUpdated to advertise the timestamp of the last change to the contents. In addition, Brand Bundles SHOULD populate Bundle.entry.resource.meta.lastUpdated with a more detailed timestamp if the system tracks updates per Resource.

Profile on Endpoint associated with a Patient Access Brand.

• extension
  • 1..* MS http://hl7.org/fhir/smart-app-launch/StructureDefinition/endpoint-fhir-version to convey the endpoint’s FHIR Version. This element is a denormalization to help clients focus on supported endpoints. The valueCode is any version from http://hl7.org/fhir/valueset-FHIR-version.html. (As of this publication, 4.0.1 is expected for ONC-certified EHRs).
• 1..1 MS status
• 1..1 MS connectionType – fixed Coding for hl7-fhir-rest
• 0..1 name fallback or default name describing the endpoint and the organization offering Patient API access at this endpoint. This value MAY contain technical details like FHIR API Version designations and apps SHOULD preferentially use names from an associated PatientAccessBrand rather than displaying this value to users.
• 1..* MS contact website where developers can configure access to this endpoint
  • 1..* MS system is url
  • 1..* MS value is an https:// URL for app developers
• 1..1 MS payloadType – fixed Coding for none
• 1..1 MS address FHIR base URL for server supporting patient access

This flag is intended to help app developers understand and debug the organizational relationships that underpin published Brands. For example, valueCode of hidden allows systems to designate Organizations as part of a hierarchy without necessarily being shown in a UX card or tile. Marking Brands hidden can also be used to associate many affiliated organizations with a parent Brand (e.g., each with its street address) without apps displaying redundant information to users. Multiple logos may be supplied. The URL can be an absolute URL with the https:// schema, or a Data URL with the data: schema that directly embeds content.

Patient access brand logo use agreement. It includes a link to terms for logo use by patient access apps.

Patient access brand logo. SHOULD be optimized for display as a 1” square and formatted as SVG or 1024x1024 pixel PNG with transparent background. Logo should be be legible at small sizes (e.g., as small as 50x50 pixels). Tips to achieve this: if the logo contains both a brandmark and a wordmark, separate them and use just the brandmark. If the logo is predominantly horizontal, consider creating a vertically-oriented logo that is still recognizable when scaled to smaller sizes. Multiple logos may be supplied. The URL can be an absolute URL with the https:// schema, or a Data URL with the data: schema that directly embeds content.

This extension references a URL for a customer-managed Patient Access Brands Bundle that defines this Brand and related Brands. It allows customers to self-publish additional information about the Brand.

The Patient Access Endpoint’s FHIR Version. This Extension is a denormalization to help clients focus on supported endpoints. (As of this publication, 4.0.1 is expected for ONC-certified EHRs).

Explains, if necessary (in patient-friendly language), the subset of patients eligible to connect and the data available. This capability supports (for example) a cancer center that uses one EHR for pediatric patients and another for adult patients. In this scenario, each EHR would publish a different PatientAccessBrand; apps would display the description to disambiguate the user’s selection. For instance, one Brand might indicate “Access records for childhood cancer care” and another might indicate “Access records for adult cancer care”.

Patient access brand portal logo use agreement. See the documentation for “brand logo use agreement”

Patient access brand portal logo. Used if the portal has its own logo in addition to the Brand’s logo. See the documentation for “brand logo”.

Indicates the name by which patients know the portal (for example, “MyChildrens” or “Patient Gateway”).

Indicates the location of the patient portal associated with this Brand - i.e., a URL where patients can go to see their data and manage access.

Patient Access Brand Flags Codes help app developers understand and debug the organizational relationships that underpin published Brands.

Categorizes a PatientAccessBrand into high-level taxonomy

Patient Access Brand Flags Codes help app developers understand and debug the organizational relationships that underpin published Brands.

Categorizes a PatientAccessBrand into high-level taxonomy

SMART App State profile on Basic resource

See App State capability for requirements, usage notes, and examples.

Defines a Task that indicates the user should launch an application using the SMART on FHIR EHR launch.

Defines a Task that indicates the user should launch an application as a standalone application.

Codes used to in profiles related to SMART on FHIR.

Defines codes for Tasks that request launch of SMART applications.

Defines Launch Type codes for Tasks that request launch of SMART applications.

Example App State

Example Task for Standalone Launch

Example Task for EHR Launch

Required capabilities for App State Server