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 HSPC communityLogica 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:
...
Because of the very general use case for which these HSPC profiles 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).
...
- a means of associating profiles, where a "simple heart rate" profile is either an inheritance child of the more general "HSPC 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 "HSPC Logica heart rate" profile
Profiles for Non-Specialized Resources
Because the HSPC profiles Logica profiles are aimed at such a general use case, the HSPC profiles 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 HSPC profile 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 "HSPC Logica Patient" profile will be created.
...
- 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.). 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.
...
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.