profiling-examples.md — FHIR Core Extract

type: docsource: source/profiling-examples.html

[%settitle Profiling FHIR%] [%file newheader%] [%file newnavbar%] [%profilesheader examples%]

Slicing and Discriminator Examples

Responsible Owner: [[%wgt fhir%]]([%wg fhir%]) Work Group	Standards Status:Informative

Slicing Patient Telecom element

One common use of slicing is to describe different constraints on different kinds of patient contact details. In this example, Patient.telecom is defined as: ContactPoint [0..*] where the ContactPoint has system, value and use.

Consider the case where the profile should say:

There must be a single home phone number
The patient may have a work phone number
The patient may have an email address
No other types of contact are allowed

An example of a patient resource that meets these rules:

To do this, the profile that implements these rules needs to do the following:

On the base Patient.telecom element: define that slicing is discriminated by system and use, and that the slices are closed ("No other types of contact are allowed"). Order is left unfixed
Then define 3 slices:
1. home phone: fixed values for system and use, and slice cardinality 1..1
2. work phone: fixed values for system and use, and slice cardinality 0..1
3. email: fixed value for system, cardinality 0..0 for use, and slice cardinality 0..1

In a StructureDefinition, this will look like:

&lt;min value="1"/&gt;
&lt;max value="3"/&gt;

</element>

Note: much of the definition detail has been left out, and only the parts relevant to the pattern are shown. Also, providing a fixed value makes the minimum cardinality irrelevant, but it is shown here for completeness.

This table illustrates the relationship between the instance and the ElementDefinitions:

	Path	Name	Min	Max	Fixed
<Patient>	Patient
	Patient.telecom		1	3
<telecom>	Patient.telecom	HomePhone	1	1
<system value="phone" />	Patient.telecom.system		1	1	phone
<value value="5551234567" />	Patient.telecom.value		1	1
<use value="home" />	Patient.telecom.use		1	1	home
</telecom>
	Patient.telecom	WorkPhone	0	1
<telecom>	Patient.telecom	Email	0	1
<system value="email" />	Patient.telecom.system		1	1	email
<value value="someone@acme.org" />	Patient.telecom.value		1	1
</telecom>	Patient.telecom.use

Fixed Order Slicing

A variant to this that looks simpler but turns out to be deceptively complicated is to fix the order and make all slices mandatory. In this case the profile says:

The cardinality of telecom is 3..3
The slicing is closed, and ordered, no discriminator
The first slice is home phone number
The second slice is work phone number
The third slice is email address

An example of a patient resource that meets these rules:

{ "resourceType" : "Patient", "telecom" : [ { "system" : "phone", "value" : "5551234567", "use" : "home" }, { "system" : "phone", "value" : "5551234567", "use" : "work" }, { "system" : "email", "value" : "someone@acme.org" } ] }

In a StructureDefinition, this will look like:

  &lt;description value="No discriminator needed since offsets are fixed"/&gt;
  &lt;rules value="closed"/&gt;
  &lt;ordered value="true"/&gt;
&lt;/slicing&gt;
<!-- cardinality rules -->
&lt;min value="3"/&gt;
&lt;max value="3"/&gt;

</element>

A simple content model like this is attractive because it's both easier to specify and to work with. There's no need to think about the values of system and use - implementers can just grab first telecom value etc.

The problem with this approach is that such simple requirements are rarely valid in production healthcare systems, and even if they are valid during implementation, they rarely stay that way. Implementing multiple applications based on simple offsets will make the overall eco-system fragile against change, either internally, or as the scope of the eco-system grows.

Since the discriminator could be system+use in this case, it's best for future compatibility to specify it anyway.

Blood Pressure Example

Another use of Slicing is for Blood Pressure Measurements, where the profile says:

There must be two components
The first has LOINC code 8480-6, and a quantity
The second has LOINC code 8462-4, and a quantity
Other components are allowed (posture, etc., but not profiled in the base blood pressure profile)

An example of an observation resource that conforms such constrained StructureDefinitions looks like this:

To do this, the profile that implements these rules needs to do the following:

On the base Observation.component element: define that slicing is discriminated by code. Order is left unfixed, and rules are left open.
Then define 2 slices:
1. systolic: fixed values for code, cardinality 1..1, value is a Quantity
2. diastolic: fixed values for code, cardinality 1..1, value is a Quantity

In a StructureDefinition, this will look like:

&lt;min value="2"/&gt;
&lt;max value="\*"/&gt;

</element>

Note: much of the definition detail has been left out, and only the parts relevant to the pattern are shown. e.g., A real blood pressure profile would fix unit, an overall Observation code etc.

Extensions

For another example, consider slicing extensions. The base extension on every element is defined as a list (0..*) of extensions, and each extension has a url that identifies it, and a value. Consider an example where a profile defines that for a particular element (named Patient), there are two extensions, with URLs http://acme.com/a and http://acme.com/b. In addition, the profile allows other extensions to be used.

Technically, the profile achieves this by "slicing" the extension list, into two slices, and saying that the slicing is "open" - that there can be other slices introduced. Here are the relevant parts of the Profile on patient:

&lt;baseType value="Patient" /&gt;
&lt;baseDefinition value="http://hl7.org/fhir/StructureDefinition/Patient" /&gt;
&lt;derivation value="constraint" /&gt;
&lt;snapshot&gt;
  &lt;element id="Patient"&gt;
    &lt;path value="Patient"/&gt;
    <!-- snip -->
  &lt;/element&gt;
  &lt;element id="Patient.extension"&gt;
    &lt;path value="Patient.extension"/&gt;
    <!-- this first element defines the slicing, and carries the base definition forward -->
    &lt;slicing&gt;
      <!-- Extensions are always discriminated by URL -->
      &lt;discriminator&gt;
        &lt;type value="value"/&gt;
        &lt;path value="url"/&gt;
      &lt;/discriminator/&gt;
      &lt;ordered value="false"/&gt;     <!-- we don't care what order they appear in -->
      &lt;rules value="open"/&gt;        <!-- other extensions can be used -->
    &lt;/slicing&gt;
    <!-- -- snip definition -->
  &lt;/element&gt;
  <!-- first extension -->
  &lt;element id="Patient.extension:name-a"&gt;
    &lt;path value="Patient.extension"/&gt;
    &lt;slicename value="name-a"/&gt; <!-- mandatory - gives the slice a name -->
    <!-- snip most of definition -->
    &lt;type&gt;
     &lt;code value="Extension"/&gt;
     <!-- the profile for an extension is a reference to the extension definition itself -
       this implies a profile, and happens to fix the @url value to the desired URL -->
     &lt;profile value="http://acme.com/a"/&gt;
    &lt;/type&gt;
  &lt;/element&gt;
  <!-- second extension -->
  &lt;element id="Patient.extension:name-b"&gt;
    &lt;path value="Patient.extension"/&gt;
    &lt;slicename value="name-b"/&gt; <!-- mandatory - gives the slice a name -->
    <!-- snip most of definition -->
    &lt;type&gt;
     &lt;code value="Extension"/&gt;
     <!-- the profile for an extension is a reference to the extension definition itself -
       this implies a profile, and happens to fix the @url value to the desired URL -->
     &lt;profile value="http://acme.com/b"/&gt;
    &lt;/type&gt;
  &lt;/element&gt;
  <!-- snip rest of profile -->
&lt;/snapshot&gt;

</StructureDefinition>

Here is a patient example that conforms to this profile:

<!-- snip whatever value extension would have -->

</extension> <extension url="http://acme.com/a">

<!-- snip whatever value extension would have -->

</extension>

</Patient>

Diagnostic Report & Observation

In this example, a profile on a diagnostic report says that it must have four observations, each with a different LOINC code (e.g., a classic lab panel). In this case (taken from the Example Lipid Profile), the structure that applies to DiagnosticReport will say that there are four slices on DiagnosticReport.result, each conforming to a different structure, which are also contained in the same profile. Each of those structures will constrain the LOINC code in the observation.

&lt;element id="DiagnosticReport.result"&gt;
  <!-- first definition for result -->
  &lt;path value="DiagnosticReport.result"/&gt;
  &lt;slicing&gt;
    <!-- this is sliced by the code value of the target of the reference -->
    &lt;discriminator&gt;
      &lt;type value="value"/&gt;
      &lt;path value="resolve().code"/&gt;
    &lt;/discriminator/&gt;
    <!-- have to be in the specified order -->
    &lt;ordered value="true"/&gt;
    <!-- this profile says, no other observations allowed -->
    &lt;rules value="closed"/&gt;
  &lt;/slicing&gt;
  <!-- snip definition -->
&lt;/element&gt;
<!-- first slice: Cholesterol -->
&lt;element id="DiagnosticReport.result:Cholesterol"&gt;
  &lt;path value="DiagnosticReport.result"/&gt;
  &lt;sliceName value="Cholesterol"/&gt;
  <!-- snip definition parts -->
  &lt;type&gt;
    &lt;code value="Reference"/&gt;
    <!-- this target must conform to the "Cholesterol" structure -->
    &lt;targetProfile value="http://acme.org/fhir/StructureDefinition/Cholesterol"/&gt;
  &lt;/type&gt;
&lt;/element&gt;
<!-- next 3 slices all the same, but different names for profile -->
&lt;element id="DiagnosticReport.result"&gt;
  &lt;path value="DiagnosticReport.result:Triglyceride"/&gt;
  &lt;sliceName value="Triglyceride"/&gt;
  <!-- snip definition parts -->
  &lt;type&gt;
    &lt;code value="Reference"/&gt;
    <!-- this target must conform to the "Triglyceride" structure -->
    &lt;targetProfile value="http://acme.org/fhir/StructureDefinition/Triglyceride"/&gt;
  &lt;/type&gt;
&lt;/element&gt;
&lt;element id="DiagnosticReport.result:LDLCholesterol"&gt;
  &lt;path value="DiagnosticReport.result"/&gt;
  &lt;sliceName value="LDLCholesterol"/&gt;
  <!-- snip definition parts -->
  &lt;type&gt;
    &lt;code value="Reference"/&gt;
    <!-- this target must conform to the "LDLCholesterol" structure -->
    &lt;targetProfile value="http://acme.org/fhir/StructureDefinition/LDLCholesterol"/&gt;
  &lt;/type&gt;
&lt;/element&gt;
&lt;element id="DiagnosticReport.result:HDLCholesterol"&gt;
  &lt;path value="DiagnosticReport.result"/&gt;
  &lt;sliceName value="HDLCholesterol"/&gt;
  <!-- snip definition parts -->
  &lt;type&gt;
    &lt;code value="Reference"/&gt;
    <!-- this target must conform to the "HDLCholesterol" structure -->
    &lt;targetProfile value="http://acme.org/fhir/StructureDefinition/HDLCholesterol"/&gt;
  &lt;/type&gt;
&lt;/element&gt;
<!-- snip elements -->