FHIR Resource Considerations

Content on this page has been migrated to Confluence here: https://confluence.hl7.org/display/FHIR/Resource+Considerations

The initial set of resources is just a starter set. The following is a more extensive list. Those already listed are in bold. Feel free to edit. All proposed resources should be expressed as a plural. If the resource content won't be obvious, provide a description. And don't be overly fussed about the categories. They're quite arbitrary. At some point we'll need to prioritize these too, but lets build the list first. (In fact, some of these will likely never be built for years, if ever. It's just useful to think about where the stuff we have built or are working on would go.)

Principles

(Also see FHIR Governance - should probably refactor that page and move some of it here)

Resources

• Resources should have a clear boundary; one that matches one or more logical transaction scopes
• Resources should differ from each other in meaning, not just in usage (e.g., each different way to use a lab report should not result in a different resource)
• Resources need to have a natural identity
• Resources should be very common and used in many different business transactions
• Resources should not be specific or detailed enough to preclude support for a wide range of business transactions
• Resources should be mutually exclusive
• Resources should use other resources, but they should be more than just compositions of other resources; each resource should introduce novel content
• Resources should be organized into a logical framework based on the commonality of the resource and what it links to (see resource framework below)
• Resources should be large enough to provide meaningful context; resources that contain only a few attributes are likely too small to provide meaningful business value
• Resources should reflect general usage
  • if most systems treat something as a single concept, that suggests a single resource; if most systems treat something as a distinct concepts, then that suggests multiple resources
  • if two different uses of a "resource" would result in wildly different interpretations of what constitutes "core" then that suggests two resources might be appropriate.

• There is a bias towards fewer resources rather than more

Resource References

General principle

• In most cases it's obvious which resource links to which
• When it's not obvious, it's probably a new linking resource. Any examples, discussion here please

Resource Governance

• Resource governance should be commensurate with the degree of commonality; the more more common a resource is, the more stringent the governance needs to be

Resource Framework

The following framework provides a guide for what to consider resources and what to consider profiles. Note that this is a framework. It is meant to be used as a starting point and as a source of reference and guidance. It is not a set of stated requirements.

Background

The resource framework is derived from the Information Organization Framework presented at the Health Informatics Conference in 2011 (reference forthcoming). Contact Bo Dagnall at bo.dagnall@gmail.com for more details.

Premise

• Healthcare domain large and complex – need to modularize
• Framework Principles
  • Predictive, not prescriptive - use the framework to predict what is a resource or profile, not to dictate
  • Separation of Concerns – seperate context-neutral from context-specific resources / profiles and optimize for a defined and dedicated purpose
  • Reuse - design resources with reuse in mind based on the commonality of the resource
• Benefits
  • Organize and manage health domains - the framework provides a basis for decomposition and modularity
  • Identify common bits - the framework teases out the common areas from the less common areas
  • Prioritize standardization work - the framework provides a structure for determining priorities and delegating work
  • Assign governance levels - the framework separates the areas needing the most stringent and universal governance from those that require more context-specific governance

First "Separation of Concerns"

The first separation of concerns is to seperate information models from terminology and instances of information artifacts. Within information models, it is important to distinguish the "Business Models" from the "Usage Models" (both of which are constrained by the Reference Model). Business models model that static structures that represent the data elements relevant to the business of healthcare. To the extent possible, business models should be usage agnostic focusing more on the core data elements and less on the "business objects" that implement the core data elements. With medications for example, the business model describes the data elements that make up a drug (including ingredients, therapeutic classes, dosage, routes, etc.), relationships that a drug has with other data elements (such as an allergy), and the basic acts associated with a drug (e.g., dispensing, administration, etc.). The usage models will describe the contents and structures of the business objects that use a drug such as a prescription, an administration record, a medication profile, etc.

.

Second "Separation of Concerns"

The next decomposition introduced by the framework is to introduce layers within the business and usage models. The layers are stacked based on their degree of commonality and/or their degree of reuse with the top layers ("Base Structures") being more common than the layers beneath them ("Extended Structures").

The business model is decomposed into four layers:

• Attribution - The who, where and when aspects of an information construct. There areas are ubiquitous and represent the most common aspects of the business model.
• Core Business - The clinical and adminstrative components that are used in nearly every healthcare transaction.
• Specializes Business - The clinical specialties that use and extend the Core Business entities in a context-specific manner
• Care Delivery Setting - The data elements that are often added to business areas to deliver care in different care settings (e.g., the unique data elements required when delivering cardiac care in a pediatric setting as opposed to the intensive care unit).

The usage model is decomposed into two layers:

• Core Compositions - The base or generic models that underpin most business transactions such as a generic order template or a summary note
• Implementable Compositions - The compositions that extend and contextualize the core compositions such as when implementing a lab order an extension of the generic base order.

The general pattern is that the Implementable Compositions will reference or extend both the Core Compositions and the Extended Structures from the Business Model. The Core Compositions will reference or extend the Base Structures from the Business Model. Data structures within layers of the business model or usage model will reference or extend each other provided that they reference data structures in the same or higher layers (i.e., more common). See the Rules and Patterns section below for more details.

.

Third "Separation of Concerns"

Within each layer, further decomposition is required to manage the breadth and complexity of health information. The framework introduces the concepts of domains as logical packages of data elements within the Business Model. Each domain represents a model fragment that is a portion of the overall model. In this regard, a domain is a view into the larger model based on the common groupings of data elements within healthcare. Many of the domains align with clinical departments or care settings, but the alignment is not meant to be prescriptive.

Domains are not as relevant and do not carry the same meaning in the Usage Model. Instead, the Usage Model is decomposed into a heirarchy of compositions.

Business Model Domains

Note that the domains in the layers of the business model shown below are a representative, but not necessarily comprehensive set of domains. Also, the domains provided are meant to provide a starting point and can be adjusted as needed based on the requirements, input from subject matter experts and/or as a result of modeling or governance activities.

.

Usage Model Compositions

The heirarchy of compositions shown below are meant to provide a representative and illustrative starting point. Modifications and additions to this set of compositions is likely.

.

Identifying Resources and Profiles

Although this framework was not developed for FHIR specifically, it is applicable to FHIR. This is because both the framework and FHIR recognize that there are inherent and variable degrees of commonality within healthcare data. Information modeling should reflect the distinction between context-neutral and context-specific data structures. The diagram below uses the framework to highlight the layers, domains and compositions recommended for consideration as FHIR resources and profiles.

The framework identifies three categories of resources:

1. Attribution resources (from the Attribution layer of the Business Model)
2. Core Business resources (from the Core Business layer of the Business Model)
3. Core Compositions (from the Core Compositions layer of the Usage Model)

The framework identifies three categories of profiles:

1. Specialized profiles (from the Specialized Business layer of the Business Model)
2. Care Delivery Setting profiles (from the the Care Delivery Setting layer of the Business Model)
3. Implementable Compositions (from the Implementable Compositions layer of the Usage Model)

.

Rules and Patterns

• Resources
  • Resources can reference other resources as long as the referenced resource is in the same or higher layer of the Business or Usage Model
  • Core Composition resources from the Usage Model should only reference resources from the Base Structures portion of the Business Model (i.e., Attribution and Core Business resources)
• Profiles
  • Profiles can reference AND extend profiles as long as the referenced profile is in the same or higher layer of the Business or Usage Model
  • Extended Structure profiles from the Business Model (i.e., Specialized Business and Care Delivery Setting profiles) can reference AND extend resources from the Base Structures portion of the Business Model (i.e., Attribution and Core Business resources)
  • Implementable Composition profiles from the Usage Model can reference AND extend Core Composition resources from the Usage Model
  • Implementable Composition profiles from the Usage MOdel should only reference AND extend profiles from the Extended Structures portion of the Business Model (i.e., Specialized Business and Care Delivery Setting profiles)

Clues you need a distinct resource

The following are hints that a resource might need to be split into multiple resources:

• There's a "Must Understand" element in the resource that's totally irrelevant in some of the common use-cases for the resource
• Common use-cases require search parameters on extensions and "core" search parameters are unneeded/irrelevant
• You're not sure how you'd filter the instances of a resource a particular profile applies to