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

Resource References

General principle

Resource Governance

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

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.


Context for Information Organization Framework

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:

The usage model is decomposed into two layers:

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.


Layers of the Information Organization Framework

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.


Business Model Domains

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.


Usage Model Compositions

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)


Identifying Resources and Profiles

Rules and Patterns

Clues you need a distinct resource

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