Use Case
These HSPC profiles Logica profiles are intended for a very general use case -- use by any system or application needing to store, capture, or exchange healthcare data.
Scope
The profiles are intended to cover the broad spectrum of healthcare. The prioritization of their creation is driven from two directions:
- 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 Logica community.)
Broad vs. Narrow Profiles
It is possible to create a FHIR profile possessing any one of a number of levels of "breadth". 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 Logica profiles are intended, the profiles are being created in a "broader" manner (like the first "heart rate measurement" example and the first "patient" example).
It is anticipated, though, that artifacts/infrastructure that support the narrower use cases (e.g., a "heart rate measurement" with only a value and a time) will be needed and desired. Possibilities include:
- a means of associating profiles, where a "simple heart rate" profile is either an inheritance child of the more general "Logica heart rate" profile or has a "is simple variant of" relationship to the "HSPC heart rate" profile
- a query model in which the "simple heart rate" is a stored query on the more general "Logica heart rate" profile
Profiles for Non-Specialized Resources
Because the Logica profiles are aimed at such a general use case, the Logica 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 Logica 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. Hence, the resource-to-profile cardinality will be one-to-one; a single "Logica Patient" profile will be created.
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
Profiles for Highly Specialized Resources
In contrast to the above approach, another approach is needed for resources that are highly specialized. Observation is the prime example. There are many, many specializations of Observation (heart rate measurement, hair color, urine description, ejection fraction, serum glucose, etc.)
...
General vs. Specific Profiles
. The structure (attributes) of the Observation varies with the specialization. For example, the applicable attributes of a heart rate measurement are different from those of a urine description. Profiles for these specializations must be very specific and will reflect greater variation from the resource; the resource-to-profile cardinality will be one-to-many.
This is where the primary value of the HSPC profiles will be found.
The Condition resource also falls in this category.
There may be FHIR resources for which a few commonly-accepted specializations exist – not nearly as many as for Observation or Condition, but where the specializations' structures are different enough and they are commonly-accepted enough that we will create separate profiles for them. To date, the only resource in this category is "Encounter". We will create an "Inpatient Encounter" profile and an "Outpatient Encounter" profile.
Laboratory Result Profiles
A special note is needed on the strategy regarding representation of laboratory results.
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.