...
- 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.)
...
Broad vs.
...
Narrow Profiles
It is possible to create a FHIR profile at possessing any one of a number of levels of generality"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 are intended, they the profiles are being created in a more general "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 "HSPC 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 heart rate" profile
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.
...
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 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.). 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.