The scope of next ballot includes catalogs of laboratory services, medications and devices. Pages which are excluded from this ballot will be signaled as such by a note to balloters at the top of the page. Feedback is welcome and may be submitted through the FHIR Jira tracker

Introduction to this guide

This implementation guide for sharing order catalogs is based on FHIR R5. Its scope is international (aka universal realm).

An order catalog is a collection of definitional resources describing healthcare items that can be ordered, selected or used by practitioners to support the course of healthcare delivery. These healthcare items may represent services, products, devices or knowledge artifacts (e.g., order sets). Each item specifies its purpose, describes how it should be ordered and/or used, and characterizes the outcomes expected from its usage.

Examples of catalogs include order sets catalog, evidence based knowledge artifacts for clinical decision support (CDS), laboratory test compendium, medication formulary, catalog of medical devices.

This universal realm implementation guide specifies the methods and artifacts based on the FHIR standard, to build catalogs of healthcare items and share the content of these catalogs across practitioners and healthcare organizations. The methods such as browse, search, retrieve, or maintain the content, are common regardless of the category of catalog at hand: product, service, clinical knowledge. Some of the artifacts, like the one representing the catalog as a whole, are also common to all categories of catalogs. Other artifacts are specific to a category of items (medication, device, order set, diagnostic service ...) exposed by the catalog.

Considering these commonalities and specificities, building a common guidance for implementing any kind of catalog of healthcare items in FHIR has been deemed the most valuable proposition to implementers. Hence this unique Order Catalog Implementation Guide, which aims to cover all categories of catalogs of healthcare items. The use cases and artifacts (profiles, extensions, semantic resources) that are specific to a particular category of catalog will be placed under the responsibility of the HL7 Working Group maintaining the base resources for this category.

How to read this Guide

This Guide is organized in a number of pages accessible from the top menu bar.

• Home: This home page provides the introduction, background and contributors to this Guide, stresses its purpose and scope as well as the roles interacting on catalogs. It also provides the general technical design for implementing catalogs of healthcare items in the FHIR standard.
• Use cases: The pages under this menu option present the use cases covered by the Guide, organized per kind of catalog:
  • Laboratory services - lists the use cases for compendium of laboratory diagnostic services.
  • Order sets - lists the use cases for library of order sets.
  • Medications - lists the use cases for catalog of drugs.
  • Devices - lists the use cases for catalog of devices.
• Specifications: The pages under this menu option provide the functional specifications, organized per kind of catalog:
  • Laboratory services - specifies the FHIR resources implemented by a compendium of laboratory diagnostic services.
  • Order sets - specifies the FHIR resources implemented by a library of order sets.
  • Medications - specifies the FHIR resources implemented by a catalog of drugs, including medication formularies.
  • Devices - specifies the FHIR resources implemented by a catalog of devices.
• Interaction Framework: The page under this menu option specifies the interaction framework applicable to all kinds of catalogs.
• Examples: The pages under this menu option present examples of catalog healthcare items. They are organized per kind of catalog:
  • Laboratory services - presents examples for compendia of laboratory diagnostic services.
  • Order sets - presents examples for libraries of order sets.
  • Medications - presents examples for catalogs of drugs.
  • Devices - presents examples for catalogs of medical devices.
• Artifact Index: The page under this menu option presents the standardized artifacts built for this Guide:
  • Profiles
  • Extension definitions
  • Value sets
  • Code systems
  • Example instances
• Downloads: The page under this menu option allows to download a copy of the artifacts and other useful information of this implementation guide.

Project and sponsoring background

This IG is one of the product deliverables of project Ordering Service Interface Specification Project #1010, which is sponsored by Orders & Observations WG, and co-sponsored by Clinical Decision Support WG, Pharmacy WG, Imaging Integration WG and Service Oriented Architecture WG. The intention is that each work group contributes on its domain of expertise, to this cross-domain FHIR IG.

Purpose of order catalogs

A catalog holds master data providing the definitions of healthcare items. It may include, where applicable, the associated regulatory constraints, business requirements and clinical guidelines for ordering and using these items.

Catalogs are most often stored on servers which make them accessible to practitioners through their IT systems or applications e.g., electronic health records, electronic medical records, computerized physcian order entry, laboratory information systems, medication dispense systems... Client applications interact with the FHIR API of a catalog server to:

• browse through entries of the catalog and retrieve items of interest together with the detailed instructions and guidance related to the usage of these items,
• import the full catalog or a part of it (e.g., recently updated items, a subset of the catalog dedicated to a specialty, ...),
• administer the content of the catalog if authorized to do so; add, update, retire items and supporting resources.

In addition, catalogs may also be exported in part or in whole to the consumer's system, using the FHIR messaging framework

Scopes of order catalogs and roles involved

Order catalogs have varied scopes, sizes, ownerships, stewardships and targeted consumers and jurisdictions. For instance an order catalog might expose the medical devices of a particular manufacturer to the potential users of these devices in a country. Another catalog might consolidate all the medical devices that are approved for use in healthcare throughout the European Union market. Another example of order catalog would be a drug formulary listing the medicinal products that are available for prescription in a particular hospital. A broader catalog of medicinal product might include all the medications authorized to the national market of a country. These examples illustrate various scopes and sizes of catalogs:

• some catalogs may expose a huge number of items, and yet the FHIR resources that implement them must have a reasonable size, which does not hamper the management (creation, update, query, retrieval) of these resources ;
• some catalogs are scoped for use within a single organization, while others address multiple organizations (or even jurisdictions) of potential consumers.

These examples also illustrate these roles involved in catalog interactions:

• Catalog consumer: A system using the content of the catalog in its own local operations in healthcare (e.g. order entry of health products or services, or application of knowledge artifacts).
• Catalog custodian: A system maintaining over time the catalog as a shareable object accessible by consumers through a FHIR interface.
• Catalog owner: A system owning the content of the catalog.

The roles of custodian and owner may belong to a single organization and in that case, be combined in a single system. Conversely, for some of the examples above these roles may be played by two distinct organizations, each with its own system, in which case, FHIR interactions are needed between these two roles to administer the content of the shared catalog.

The interactions between those three roles are described in the Interaction Framework of this guide.

Out of Scope

• A catalog conformant to this IG does not contain any personal health data, and therefore presents no risk of privacy breach. Thus, ensuring privacy by design is out of scope of this IG.
• A catalog conforming to this guide is a collection of definitional resources, originated by a single actor: the catalog owner, and shared on the FHIR API by a single actor - the catalog custodian. There is no need to trace and reconcile update activities of multiple actors on any of the resources of the catalog. Data provenance is therefore known a priori. This is why handling data provenance with the Provenance resource is out of scope of this IG.
• Definitional resources describing an orderable item of the catalog guide the generation of orders of this item, as well as reports fulfilling these orders. The exact methods for generating the workflow resources from the definitional resources depend on the standard chosen (HL7 v2, FHIR) to convey the workflow objects (orders, tasks, reports ...). The definition of these methods is currently beyond the scope of this IG.

Technical Overview

In the FHIR standard, an order catalog as a whole is represented by an instance of the Composition resource, which conveys the general properties of the catalog (e.g. custodian, title, period of validity, type of content), and each item of the catalog is represented by a definitional resource, possibly associated with a set of supporting resources providing further details on this item. Two alternative methods are usable to bind the catalog as a whole to its items.

1. The catalog references its items from its Composition.section.entry elements. This method constrains the Composition resource with the Catalog profile, which is part of the base standard.
2. Each definitional resource representing an item references the Composition resource. The Composition resource in this case acts as the header of the catalog. This method constrains the Composition resource with the CatalogHeader profile.

The catalog custodian may support both methods. It is recommended to choose one method for a catalog instance. Usable for catalogs of any size, the second method is more appropriate for large catalogs because it makes the administration of the content easier. In particular, adding a new item or retiring an item does not impose any update to the Catalog or the CatalogHeader resource representing the catalog as a whole.

Authors and Contributors

Role	Name	Organization
Primary Editor	François Macary	Phast
Primary Editor	Rob Hausam	Hausam Consulting LLC
Contributor	Freida Hall	Quest Diagnostics
Contributor	Gary Randman	Quest Diagnostics
Contributor	Kathy Walsh	LabCorp
Contributor	Andrea Pitkus	U of Wisconsin
Contributor	Jose Costa Teixeira	Independent
Contributor	Marti Velezis	Sonrisa