<StructureDefinition xmlns="http://hl7.org/fhir">
  <meta>
    <lastUpdated value="2017-10-16T05:05:58.193-04:00" />
  </meta>
  <extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-wg">
    <valueCode value="dev" />
  </extension>
  <url value="http://pchalliance.org/phdfhir/StructureDefinition/PhdChildDeviceComponent" />
  <name value="PhdChildDeviceComponent" />
  <status value="draft" />
  <date value="2017-07-07T11:39:51.3383228-04:00" />
  <description value="Base StructureDefinition for the child DeviceComponent Resource for a PHD" />
  <purpose value="This resource describes the specializations of a HYDRA PHD. Each supported specialization is represented in a child DeviceComponent, THe Observations from this specialization point to this child DeviceComponent which, in turn, points to another child DeviceComponent or parent DeviceComponent. A child DeviceComponent may have a child DeviceComponent if the PHD also supports a sub-profile of a specialization." />
  <fhirVersion value="3.0.0" />
  <kind value="resource" />
  <abstract value="false" />
  <type value="DeviceComponent" />
  <baseDefinition value="http://hl7.org/fhir/StructureDefinition/DeviceComponent" />
  <derivation value="constraint" />
  <differential>
    <element id="DeviceComponent">
      <path value="DeviceComponent" />
      <comment value="For PHDs child DeviceComponents need only populate the type and parent elements of the DeviceComponent specific elements. The remaining elements are already defined in the parentDeviceComponent since a PHD is a single static unit. There is no need to repeat them here.&#xD;&#xA;&#xD;&#xA;In some sense there is a strong semantic argument for the child DeviceComponents being a contained resource of the parentDeviceComponent. but that is not possible as there is no way to reference the contained resource from the DeviceComponent resource that would contain it." />
    </element>
    <element id="DeviceComponent.meta">
      <path value="DeviceComponent.meta" />
      <min value="1" />
    </element>
    <element id="DeviceComponent.meta.profile">
      <path value="DeviceComponent.meta.profile" />
      <slicing>
        <discriminator>
          <type value="value" />
          <path value="PhdChildDeviceComponent" />
        </discriminator>
        <rules value="open" />
      </slicing>
      <min value="1" />
    </element>
    <element id="DeviceComponent.meta.profile:phdProfile">
      <path value="DeviceComponent.meta.profile" />
      <sliceName value="phdProfile" />
      <min value="1" />
      <max value="1" />
      <fixedUri value="PhdChildDeviceComponent" />
    </element>
    <element id="DeviceComponent.identifier">
      <path value="DeviceComponent.identifier" />
      <slicing>
        <discriminator>
          <type value="value" />
          <path value="system" />
        </discriminator>
        <ordered value="true" />
        <rules value="open" />
      </slicing>
      <short value="A means to uniquely identify the semantic content of the entity" />
      <definition value="This element is used to distinguish the semantic content of the resource in some unique way. For PHDs the required identifiers are present in the parent which this resource is considered part of." />
      <comment value="In future versions of FHIR the cardinality of this element will become [0..*] and this element will be used to report the system id and optionally the transport address." />
      <min value="0" />
      <max value="*" />
    </element>
    <element id="DeviceComponent.type">
      <path value="DeviceComponent.type" />
      <definition value="The PHD specialization/sub-profile as defined in the System-Type-Spec list attribute when the attribute has more than one entry." />
      <comment value="PHDs can support multiple specializations in a simple manner. Whereas PoCDs support multiple specializations using multiple VMDs, a PHD simply exposes the objects defined in different specialization standards and indicates that in the System-Type-Spec-List attribute. Technically that usually means the PHD has more than one sensor unit. The situation is not common, but to handle the situation should it occur, each specialization is represented in its own child DeviceComponent in this element. If the PHD also supports a sub profile, such as a step counter sub profile of the cardiovascular specialization, the sub-profile would be a child of the DeviceComponent whose type is the Cardiovascular specialization. That DeviceComponent could be a child or a parent depending upon what elese the PHD supports. Observations coming from objects of the step counter would point to the child DeviceComponent representing the step-counter sub-profile which would in turn point to a child or parent DeviceComponent representing the Cardiovascular specialization which would, if a child, point to the parent DeviceComponent containing HYDRA." />
    </element>
    <element id="DeviceComponent.type.coding">
      <path value="DeviceComponent.type.coding" />
      <slicing>
        <discriminator>
          <type value="value" />
          <path value="system" />
        </discriminator>
        <ordered value="true" />
        <rules value="open" />
      </slicing>
      <min value="1" />
    </element>
    <element id="DeviceComponent.type.coding:11073Type">
      <path value="DeviceComponent.type.coding" />
      <sliceName value="11073Type" />
      <min value="1" />
      <max value="1" />
    </element>
    <element id="DeviceComponent.type.coding:11073Type.system">
      <path value="DeviceComponent.type.coding.system" />
      <short value="Identifies IEEE 11073 10101" />
      <definition value="This value identifies the IEEE 11073 10101 coding system" />
      <min value="1" />
      <fixedUri value="urn:iso:std:iso:11073:10101" />
    </element>
    <element id="DeviceComponent.type.coding:11073Type.code">
      <path value="DeviceComponent.type.coding.code" />
      <short value="Device specialization code" />
      <definition value="The device specialization or sub profile code obtained from the System-Type-Spec-List attribute when the attribute has has multiple entries. The attribute provides only the term code, the partition is always 'infra' which has value 8. Thus the code will be 8*2**16 + term code." />
      <min value="1" />
    </element>
    <element id="DeviceComponent.type.coding:11073Type.display">
      <extension url="http://hl7.org/fhir/StructureDefinition/elementdefinition-translatable">
        <valueBoolean value="true" />
      </extension>
      <path value="DeviceComponent.type.coding.display" />
      <definition value="A human readable display descrbing the meaning of the code." />
      <comment value="This element should contain the reference identfier for the reported code." />
    </element>
    <element id="DeviceComponent.lastSystemChange">
      <path value="DeviceComponent.lastSystemChange" />
      <definition value="This element is excluded for PHDs" />
      <comment value="A PHD is static and does not change and the appropriate value for this entry would be its manufacture date. However, this information is not available by protocol and shall not be used. Its absence indicates a static unit." />
      <max value="0" />
    </element>
    <element id="DeviceComponent.source">
      <path value="DeviceComponent.source" />
      <definition value="The link to the source Device that contains administrative device information such as manufacture, serial number, etc.&#xD;&#xA;This element is not used for PHDs" />
      <comment value="PHDs are considered medical devices only and are not part of a device complex which PoCD devices might be. The DeviceComponent is considered to represent the medical device subset of a device complex and since that is all a PHD is, this element is typcially not used." />
      <max value="0" />
    </element>
    <element id="DeviceComponent.parent">
      <path value="DeviceComponent.parent" />
      <definition value="The link to the Personal Health Gateway (PHG) that processed the sensor data and converted it to FHIR" />
      <comment value="This element shall be present if a PHG is involved in generating the FHIR data." />
      <requirements value="The PHG does limited correction of the received data; in particular, any errors in the time line and mapping the time line to local time plus UTC offset" />
      <min value="1" />
    </element>
    <element id="DeviceComponent.parent.reference">
      <path value="DeviceComponent.parent.reference" />
      <definition value="A reference to the parentDeviceComponent if a specialization or to the DeviceComponent representing the specialization if this childDeviceComponent represents a sub-profile of that specialziation" />
      <comment value="Child DeviceComponents can be either specializations or sub profiles of a specialization. If a specialization, this reference points to the parentDeviceComponent containing HYDRA. If a sub-profile, this reference points to the DeviceComponent containing the specialization that this is a sub profile of. That may either be another child DeviceComponent or a parentDeviceComponent. The latter is more frequent in PHDs than the former." />
      <min value="1" />
    </element>
    <element id="DeviceComponent.operationalStatus">
      <path value="DeviceComponent.operationalStatus" />
      <definition value="For a PHD, if used, this element is covered in the parent" />
      <comment value="OperationalStatus for the MDS, VMD, or Channel will be bound to a specific ValueSet that is defined in its profile. A PHD is always on and if used, the status is covered in the parent and not the child so this element is not used." />
      <max value="0" />
    </element>
    <element id="DeviceComponent.parameterGroup">
      <path value="DeviceComponent.parameterGroup" />
      <definition value="For a PHD, if used, this element is covered in the parent" />
      <comment value="Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination.&#xD;&#xA;This information is not available by protocol from the PHD and if used is covered in the parent. Therefore it is excluded in child DeviceComponents." />
      <max value="0" />
    </element>
    <element id="DeviceComponent.measurementPrinciple">
      <path value="DeviceComponent.measurementPrinciple" />
      <definition value="For a PHD, if used, this element is covered in the parent" />
      <comment value="This information is not available fron PHD devices by protocol. If used it is in the parentDeviceComponent and excluded here." />
      <max value="0" />
    </element>
    <element id="DeviceComponent.productionSpecification">
      <path value="DeviceComponent.productionSpecification" />
      <definition value="The production specification such as component revision, serial number, etc. A PHD is a single static unit and the Production specification is present in the parent DeviceComponent" />
      <comment value="For a PHD this element is covered in the parent" />
      <max value="0" />
    </element>
    <element id="DeviceComponent.productionSpecification.specType.coding">
      <path value="DeviceComponent.productionSpecification.specType.coding" />
      <slicing>
        <discriminator>
          <type value="value" />
          <path value="system" />
        </discriminator>
        <ordered value="true" />
        <rules value="open" />
      </slicing>
    </element>
    <element id="DeviceComponent.languageCode">
      <path value="DeviceComponent.languageCode" />
      <comment value="For a PHD, if used, this element is covered in the parent" />
      <max value="0" />
    </element>
  </differential>
</StructureDefinition>