Order Catalog Implementation Guide, published by HL7 International - Orders and Observations Work Group. This is not an authorized publication; it is the continuous build for version current). This version is based on the current content of https://github.com/HL7/fhir-order-catalog/ and changes regularly. See the Directory of published versions
Order Catalog Home Page
Official URL: http://hl7.org/fhir/uv/order-catalog/ImplementationGuide/hl7.fhir.uv.order-catalog
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 trackerIntroduction to this guideThis 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 homogeneous healthcare items that can be
ordered, selected or used by practitioners to support the course of healthcare delivery. These
homogeneous 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: ProfilesExtension definitionsValue setsCode systemsExample instancesDownloads: 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 backgroundThis 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 frameworkScopes 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 ScopeA 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. 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.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 ContributorsRoleNameOrganizationPrimary EditorFrançois MacaryPhastPrimary EditorRob HausamHausam Consulting LLCContributorFreida HallQuest DiagnosticsContributorGary RandmanQuest DiagnosticsContributorKathy WalshLabCorpContributorAndrea PitkusU of WisconsinContributorJose Costa TeixeiraIndependentContributorMarti VelezisSonrisa