...
These HSPC profiles are intended for a very general use case -- use by any system or application needing to store, capture, or exchange healthcare data.
...
- Profiles for resources that are commonly used in healthcare (patient, encounter, procedure, medication administration, allergy/intolerance, observation, etc.) will be created as a high priority.
- Since currently the team creating the resources is from Intermountain Healthcare, profiles for resources that are required by Intermountain Healthcare applications will also be created. (This does not preclude the creation of other profiles by other parties and their promotion within the HSPC community.)
General vs. Specific Profiles
It is possible to create a FHIR profile at any one of a number of levels of generality. For example, a heart rate measurement profile might be created against the FHIR Observation resource and contain the following elements/extensions:
- value
- time of measurement
- body position of the patient at the time of measurement
- method of measurement
- body location at which the measurement was taken
- device used for measurement
On the other hand, a heart rate measurement profile might just contain the following:
- value
- time of measurement
The first example is much more robust, serving a greater variety of use cases. The second, however, might be much preferred for its simplicity in a narrower use case in which the value and the time are the only attributes needed.
Similarly, a FHIR profile for a "patient" might contain the following:
- name
- address
- gender
- date of birth
- identifier
- religion
- race
- birth order
- veteran military status
Or a "patient" profile may contain only the following:
- name
- address
- gender
- date of birth
- identifier
Which is preferred would depend on the use case, the first being preferable for patient registration while the second being preferred for most typical clinical applications.
Because of the very general use case for which these HSPC profiles are intended, they are being created in a more general manner (like the first "heart rate measurement" example and the first "patient" example).
Profiles for non-specialized resources
Because the HSPC profiles are aimed at such a general use case, the HSPC profiles being created for many resources will differ little from the FHIR resources themselves. The profiles will extend the resources with a few extensions for attributes that are not presently contained as elements in the FHIR resources but that the community has found useful1.
They may also constrain some FHIR elements out of the resources. For example, the FHIR medication-related resources (medication statement and medication administration) have resource references to the Medication resource, which contains a full description of the medication, including lot number and manufacturer. This Medication resource contains such detail so as to be reusable by the widest variety of other resources as possible. For instance, it is referred to by both the "Supply" resource and the "Medication Administration" resource. However, in a typical use of a "Medication Administration" (even in the very general use case), such detail is not required. Consequently, the HSPC profile will constrain out some elements of the Medication statement.
This strategy applies to resources of which little specialization occurs. For example, a few specializations of Patient can be conceived of ("Inpatient", "Outpatient", etc.), but those specializations do not appreciably change the structure (i.e., the attributes) of the resource.
Under these assumptions and this strategy, then, HSPC profiles for FHIR resources such as the following (not an exhaustive list) will likely differ little from the FHIR resources themselves:
- Patient
- Practitioner
- Location
- Organization
- AllergyIntolerance
- MedicationAdministration
- MedicationStatement
1We hope, though, that if the community has found something useful that FHIR has not included, FHIR will be willing to add it to its specification.