{
  "resourceType": "StructureDefinition",
  "meta": {
    "lastUpdated": "2017-10-16T09:05:58.193+00:00"
  },
  "extension": [
    {
      "url": "http://hl7.org/fhir/StructureDefinition/structuredefinition-wg",
      "valueCode": "dev"
    }
  ],
  "url": "http://pchalliance.org/phdfhir/StructureDefinition/PhdChildDeviceComponent",
  "name": "PhdChildDeviceComponent",
  "status": "draft",
  "date": "2017-07-07T15:39:51.3383228+00:00",
  "description": "Base StructureDefinition for the child DeviceComponent Resource for a PHD",
  "purpose": "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": "3.0.0",
  "kind": "resource",
  "abstract": false,
  "type": "DeviceComponent",
  "baseDefinition": "http://hl7.org/fhir/StructureDefinition/DeviceComponent",
  "derivation": "constraint",
  "differential": {
    "element": [
      {
        "id": "DeviceComponent",
        "path": "DeviceComponent",
        "comment": "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.\r\n\r\nIn 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."
      },
      {
        "id": "DeviceComponent.meta",
        "path": "DeviceComponent.meta",
        "min": 1
      },
      {
        "id": "DeviceComponent.meta.profile",
        "path": "DeviceComponent.meta.profile",
        "slicing": {
          "discriminator": [
            {
              "type": "value",
              "path": "PhdChildDeviceComponent"
            }
          ],
          "rules": "open"
        },
        "min": 1
      },
      {
        "id": "DeviceComponent.meta.profile:phdProfile",
        "path": "DeviceComponent.meta.profile",
        "sliceName": "phdProfile",
        "min": 1,
        "max": "1",
        "fixedUri": "PhdChildDeviceComponent"
      },
      {
        "id": "DeviceComponent.identifier",
        "path": "DeviceComponent.identifier",
        "slicing": {
          "discriminator": [
            {
              "type": "value",
              "path": "system"
            }
          ],
          "ordered": true,
          "rules": "open"
        },
        "short": "A means to uniquely identify the semantic content of the entity",
        "definition": "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": "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": 0,
        "max": "*"
      },
      {
        "id": "DeviceComponent.type",
        "path": "DeviceComponent.type",
        "definition": "The PHD specialization/sub-profile as defined in the System-Type-Spec list attribute when the attribute has more than one entry.",
        "comment": "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."
      },
      {
        "id": "DeviceComponent.type.coding",
        "path": "DeviceComponent.type.coding",
        "slicing": {
          "discriminator": [
            {
              "type": "value",
              "path": "system"
            }
          ],
          "ordered": true,
          "rules": "open"
        },
        "min": 1
      },
      {
        "id": "DeviceComponent.type.coding:11073Type",
        "path": "DeviceComponent.type.coding",
        "sliceName": "11073Type",
        "min": 1,
        "max": "1"
      },
      {
        "id": "DeviceComponent.type.coding:11073Type.system",
        "path": "DeviceComponent.type.coding.system",
        "short": "Identifies IEEE 11073 10101",
        "definition": "This value identifies the IEEE 11073 10101 coding system",
        "min": 1,
        "fixedUri": "urn:iso:std:iso:11073:10101"
      },
      {
        "id": "DeviceComponent.type.coding:11073Type.code",
        "path": "DeviceComponent.type.coding.code",
        "short": "Device specialization code",
        "definition": "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": 1
      },
      {
        "id": "DeviceComponent.type.coding:11073Type.display",
        "extension": [
          {
            "url": "http://hl7.org/fhir/StructureDefinition/elementdefinition-translatable",
            "valueBoolean": true
          }
        ],
        "path": "DeviceComponent.type.coding.display",
        "definition": "A human readable display descrbing the meaning of the code.",
        "comment": "This element should contain the reference identfier for the reported code."
      },
      {
        "id": "DeviceComponent.lastSystemChange",
        "path": "DeviceComponent.lastSystemChange",
        "definition": "This element is excluded for PHDs",
        "comment": "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": "0"
      },
      {
        "id": "DeviceComponent.source",
        "path": "DeviceComponent.source",
        "definition": "The link to the source Device that contains administrative device information such as manufacture, serial number, etc.\r\nThis element is not used for PHDs",
        "comment": "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": "0"
      },
      {
        "id": "DeviceComponent.parent",
        "path": "DeviceComponent.parent",
        "definition": "The link to the Personal Health Gateway (PHG) that processed the sensor data and converted it to FHIR",
        "comment": "This element shall be present if a PHG is involved in generating the FHIR data.",
        "requirements": "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": 1
      },
      {
        "id": "DeviceComponent.parent.reference",
        "path": "DeviceComponent.parent.reference",
        "definition": "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": "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": 1
      },
      {
        "id": "DeviceComponent.operationalStatus",
        "path": "DeviceComponent.operationalStatus",
        "definition": "For a PHD, if used, this element is covered in the parent",
        "comment": "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": "0"
      },
      {
        "id": "DeviceComponent.parameterGroup",
        "path": "DeviceComponent.parameterGroup",
        "definition": "For a PHD, if used, this element is covered in the parent",
        "comment": "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.\r\nThis 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": "0"
      },
      {
        "id": "DeviceComponent.measurementPrinciple",
        "path": "DeviceComponent.measurementPrinciple",
        "definition": "For a PHD, if used, this element is covered in the parent",
        "comment": "This information is not available fron PHD devices by protocol. If used it is in the parentDeviceComponent and excluded here.",
        "max": "0"
      },
      {
        "id": "DeviceComponent.productionSpecification",
        "path": "DeviceComponent.productionSpecification",
        "definition": "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": "For a PHD this element is covered in the parent",
        "max": "0"
      },
      {
        "id": "DeviceComponent.productionSpecification.specType.coding",
        "path": "DeviceComponent.productionSpecification.specType.coding",
        "slicing": {
          "discriminator": [
            {
              "type": "value",
              "path": "system"
            }
          ],
          "ordered": true,
          "rules": "open"
        }
      },
      {
        "id": "DeviceComponent.languageCode",
        "path": "DeviceComponent.languageCode",
        "comment": "For a PHD, if used, this element is covered in the parent",
        "max": "0"
      }
    ]
  }
}