{
  "resourceType": "StructureDefinition",
  "meta": {
    "lastUpdated": "2017-10-16T09:03:37.38+00:00"
  },
  "extension": [
    {
      "url": "http://hl7.org/fhir/StructureDefinition/structuredefinition-wg",
      "valueCode": "dev"
    }
  ],
  "url": "http://pchalliance.org/phdfhir/StructureDefinition/PhdParentDeviceComponent",
  "name": "PhdParentDeviceComponent",
  "status": "draft",
  "date": "2017-07-07T15:39:51.3383228+00:00",
  "description": "Base StructureDefinition for the parent DeviceComponent Resource for a PHD",
  "purpose": "This resource describes the primary features of a Personal Health Device (PHD). It is referred to as the 'parent' resource since it contains the properties, production specification, and overall type of the PHD. In most cases, a PHD will only have a parent. A child DeviceComponent happens when the PHD happens to support more than one specialization. The child component will only contain information about the 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",
        "definition": "The characteristics, operational status and capabilities of a medical-related component of a medical device. A PHD is JUST the medical-related component.",
        "comment": "For the initial scope, this DeviceComponent resource is only applicable to describe a single node in the containment tree that is produced by the context scanner in any medical device that implements or derives from the ISO/IEEE 11073 standard and that does not represent a metric. Examples for such a node are MDS, VMD, or Channel.\r\n\r\nWith PHD medical units, there is no medical scanner and the unit is only a single node, a single 'simple' MDS, and it is static. Thus a PHD has no parent 'Device'.  When a PHD supports multiple device specializations, the single unit description is still the case. A specialization is just an way to organize a set of metric objects that tend to be generated by a single sensor, but the device could expose metric objects from several specializations which usually means it has more than one sensor. In PHDs that is rare. Since FHIR does not have a means to list multiple types for the DeviceComponent resource, child DeviceComponents are used to expose these additional specializations should they occur.\r\n\r\nChild DeviceComponents can appear in two ways, a single specialization that supports one or more sub-profiles, or a hydra PHD that supports multiple specializations."
      },
      {
        "id": "DeviceComponent.meta",
        "path": "DeviceComponent.meta",
        "min": 1
      },
      {
        "id": "DeviceComponent.meta.profile",
        "path": "DeviceComponent.meta.profile",
        "slicing": {
          "discriminator": [
            {
              "type": "value",
              "path": "phdParentDeviceComponent"
            }
          ],
          "rules": "open"
        },
        "min": 1
      },
      {
        "id": "DeviceComponent.meta.profile:phdProfile",
        "path": "DeviceComponent.meta.profile",
        "sliceName": "phdProfile",
        "min": 1,
        "max": "1",
        "fixedUri": "phdParentDeviceComponent"
      },
      {
        "id": "DeviceComponent.identifier",
        "path": "DeviceComponent.identifier",
        "slicing": {
          "discriminator": [
            {
              "type": "value",
              "path": "system"
            }
          ],
          "ordered": true,
          "rules": "open"
        },
        "short": "Information that uniquely describes the device",
        "definition": "The locally assigned unique identification of the device that is semantically meaningful outside of the FHIR resource context. An example would be the IEEE EUI-64 System-Id or transport address. For PHDs the systemIdentifier is required and the transportAddressIdentifier is highly recommended as this is what most end users see and can obtain from the device itself or device packaging.",
        "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.",
        "max": "*"
      },
      {
        "id": "DeviceComponent.identifier:systemIdIdentifier",
        "path": "DeviceComponent.identifier",
        "sliceName": "systemIdIdentifier",
        "short": "IEEE EUI-64 identifier",
        "definition": "This entry contains the IEEE EUI-64. If absent (bad device) set to all zeros.",
        "min": 1
      },
      {
        "id": "DeviceComponent.identifier.system",
        "path": "DeviceComponent.identifier.system",
        "short": "IEEE EUI-64 identifier",
        "definition": "Identifies the system as an IEEE EUI.",
        "min": 1,
        "fixedUri": "urn:oid:1.2.840.10004.1.1.1.0.0.1.0.0.1.2680"
      },
      {
        "id": "DeviceComponent.identifier.value",
        "path": "DeviceComponent.identifier.value",
        "definition": "The System id from the System-Id attribute as an 8-byte HEX string where each byte is separated by dashes, for example FE-ED-AB-EE-DE-AD-77-C3.",
        "comment": "The formatting is specified in the IEEE document Guidelines for 64-bit Global Identifier.\r\n\r\nTo allow the mapping of naughty, non-compliant proprietary devices that do not provide a system id, the value is set to all zeros in the same format, 00-00-00-00-00-00-00-00",
        "min": 1
      },
      {
        "id": "DeviceComponent.identifier:transportAddressIdentifier",
        "path": "DeviceComponent.identifier",
        "sliceName": "transportAddressIdentifier",
        "short": "Transport address identifier",
        "definition": "This entry contains the transport address, for example the Bluetooth, ZigBee, USB, or mac address.",
        "comment": "USB does not have an 'address' as it is a point to point wired protocol. However, it does have a Vendor identification and Production identification number which together uniquely define the unit. For USB transports, the VID.PID in HEX is used as the transport identifier."
      },
      {
        "id": "DeviceComponent.identifier.system",
        "path": "DeviceComponent.identifier.system",
        "min": 1
      },
      {
        "id": "DeviceComponent.identifier.value",
        "path": "DeviceComponent.identifier.value",
        "definition": "The transport address. If Bluetooth, use an EUI-48 such as 00-E5-DE-AD-77-C3. If a USB device use the VID.PID as HEX such as 0043.F90D. If a ZigBee address use an EUI-64 as with the system id. If a TCP/IP address use the standard IP address format such as 192.168.127.4",
        "comment": "Transport addresses are supposed to be unique for a given device.",
        "min": 1
      },
      {
        "id": "DeviceComponent.type",
        "path": "DeviceComponent.type",
        "definition": "The type or 'specialization' of the PHD.",
        "comment": "In most cases a PHD supports only a single specialization such as a Blood Pressure monitor and only one DeviceComponent is needed and that specialization is recorded in this element. Since there is no way to indicate additional supported specialziations with this element (it has cardinality 1..1), additional child DeviceComponents are needed when multiple specializations and/or sub-profiles are present.\r\n\r\nThe value entered in this element comes from the System-Type-Spec-List attribute which is unique to the 11073 20601 specification; 11073-10201 does not have such an attribute. If there is more than one specialization, the special HYDRA specialization value is entered here and child DeviceComponent resources are used to map the specializations. If there is only a single specialization but one or more sub profiles., the specialization is entered here and the sub profiles are handled in child DeviceComponents.\r\n\r\nNote that sub-profiles are a packaging of objects within a specialization that serve a special use case. For example, the Cardiovascular specialization has numerous objects that can represent all kinds of physical activities from treadmills to skiing. One sub-profile is a minimum set of objects needed to describe a step counter."
      },
      {
        "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",
        "definition": "The 11073 10101 code for the PHD specialization.",
        "comment": "This coding is provided by the System-Type-Spec-List attribute. Note that PoCDs do not have a System-Type-Spec-List but express specializations in different VMD objects.",
        "min": 1,
        "max": "1"
      },
      {
        "id": "DeviceComponent.type.coding.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.code",
        "path": "DeviceComponent.type.coding.code",
        "short": "Device specialization code",
        "definition": "The device specialization is obtained from the System-Type-Spec-List attribute if the attribute has only a single entry or only a single specialization with one or more sub profiles from that specialization. If it has multiple specializations, this value is fixed to 'hydra' and there will be child DeviceComponent resources handling the specializations. 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.\r\n\r\nWhen 'hydra' is used, the code is 528384 and the reference id is MDC_DEV_SPEC_PROFILE_HYDRA",
        "min": 1
      },
      {
        "id": "DeviceComponent.type.coding.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 specialization code."
      },
      {
        "id": "DeviceComponent.lastSystemChange",
        "path": "DeviceComponent.lastSystemChange",
        "definition": "The timestamp for the most recent system change which includes device configuration or setting change. This field is not provided by PHD devices via standardized exchange protocols and is, therefore, not required in this profile.",
        "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",
        "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 not used.",
        "max": "0"
      },
      {
        "id": "DeviceComponent.parent",
        "path": "DeviceComponent.parent",
        "definition": "The link to the DeviceComponent resource representing 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"
      },
      {
        "id": "DeviceComponent.parent.reference",
        "path": "DeviceComponent.parent.reference",
        "definition": "A reference to a location at which the PHG resource is found. The reference may be a relative reference, in which case it is relative to the service base URL, or an absolute URL that resolves to the location where the resource is found. The reference may be version specific or not. If the reference is not to a FHIR RESTful server, then it should be assumed to be version specific. Internal fragment references (start with '#') refer to contained resources.",
        "min": 1
      },
      {
        "id": "DeviceComponent.operationalStatus",
        "path": "DeviceComponent.operationalStatus",
        "comment": "OperationalStatus for the MDS, VMD, or Channel will be bound to a specific ValueSet that is defined in its profile. If used, a PHD is considered to be always on"
      },
      {
        "id": "DeviceComponent.parameterGroup",
        "path": "DeviceComponent.parameterGroup",
        "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\n\r\nThis information is not available by protocol from the PHD and its use is up to the application."
      },
      {
        "id": "DeviceComponent.measurementPrinciple",
        "path": "DeviceComponent.measurementPrinciple",
        "comment": "This information is not available fron PHD devices by protocol. Its use is up to the implementation."
      },
      {
        "id": "DeviceComponent.productionSpecification",
        "path": "DeviceComponent.productionSpecification",
        "definition": "The production specification such as component revision, serial number, etc. For the 11073 20601 Personal Health Device, the production specification entries come from the Production-Specification, System-Model, and Reg-Cert-Data-List attributes. There will be one productionSpecification entry for each item to be reported.",
        "comment": "All the PHD productionSpecification entries are strings and have IEEE 11073-10101 codes that define which production specification the string represents. Compliant PHDs will always have at least some entries for this element. If the PHD reports one or more such entries, they shall be recorded here. However, to allow the mapping of naughty proprietary devices, this element is made technically optional."
      },
      {
        "id": "DeviceComponent.productionSpecification.specType",
        "path": "DeviceComponent.productionSpecification.specType",
        "min": 1
      },
      {
        "id": "DeviceComponent.productionSpecification.specType.coding",
        "path": "DeviceComponent.productionSpecification.specType.coding",
        "slicing": {
          "discriminator": [
            {
              "type": "value",
              "path": "system"
            }
          ],
          "ordered": true,
          "rules": "open"
        },
        "min": 1
      },
      {
        "id": "DeviceComponent.productionSpecification.specType.coding:11073Type",
        "path": "DeviceComponent.productionSpecification.specType.coding",
        "sliceName": "11073Type",
        "short": "The 11073-10101 code",
        "definition": "The 11073-10101 code defining what the productionSpec is",
        "comment": "11073 10101 codes have been defined for the Production-Specification and System-Model sub entries for use in V2 messaging. Though FHIR has provided its own set of codes based upon the names of the 11073-* Production-Specification.spec-type entry, the 11073-10101 codes are used since they are ubiquitous in these PHD-related profiles and it helps accelerate the acceptance of the MDC coding system in HL7.",
        "min": 1,
        "max": "1"
      },
      {
        "id": "DeviceComponent.productionSpecification.specType.coding.system",
        "path": "DeviceComponent.productionSpecification.specType.coding.system",
        "short": "Specifies IEEE 11073 10101",
        "definition": "Identifies the IEEE 11073 10101 coding system",
        "comment": "These codes are not seen on the wire between the PHD and the PHG. They are seen on the wire in PCD-01 messages.",
        "min": 1,
        "fixedUri": "urn:iso:std:iso:11073:10101"
      },
      {
        "id": "DeviceComponent.productionSpecification.specType.coding.code",
        "path": "DeviceComponent.productionSpecification.specType.coding.code",
        "short": "actual code",
        "definition": "The 32 bit code identifying what the string in the DeviceComponent.productionSpecification.productionSpec element is.",
        "comment": "The currently defined codes used in this element are as follows:\r\n\r\nFIELD                                 CODE                  reference identifier\r\n------------------------------------------------------------------------------------\r\nModel number                 531969            MDC_ID_MODEL_NUMBER\r\nManufacturer name         531970            MDC_ID_MODEL_MANUFACTURER\r\n                  The above come from the System-Model attribute\r\n\r\nUnspecified                      531971            MDC_ID_PROD_SPEC_UNSPECIFIED\r\nSerial number                  531972            MDC_ID_PROD_SPEC_SERIAL\r\nPart number                     531973            MDC_ID_PROD_SPEC_PART\r\nHardware revision            531974            MDC_ID_PROD_SPEC_HW\r\nSoftware revision             531975            MDC_ID_PROD_SPEC_SW\r\nFirmware revision            531976            MDC_ID_PROD_SPEC_FW\r\nProtocol                           531977            MDC_ID_PROD_SPEC_PROTOCOL\r\nGlobal Medical Device\r\nNomenclature (GMDN)    531978           MDC_ID_PROD_SPEC_GMDN\r\n                   The above come from the Production-Specification attribute\r\n\r\nContinua version              532352           MDC_REG_CERT_DATA_CONTINUA_VERSION\r\n                    The above comes from the Continua Reg-Cert-Data-List attribute\r\n\r\nThere may be more fields added in future versions of the 10101 specification.",
        "requirements": "Need to identify what the reported string value represents",
        "min": 1
      },
      {
        "id": "DeviceComponent.productionSpecification.specType.coding.display",
        "extension": [
          {
            "url": "http://hl7.org/fhir/StructureDefinition/elementdefinition-translatable",
            "valueBoolean": true
          }
        ],
        "path": "DeviceComponent.productionSpecification.specType.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.productionSpecification.specType.coding:fhirCoding",
        "path": "DeviceComponent.productionSpecification.specType.coding",
        "sliceName": "fhirCoding",
        "short": "The IEEE concept in the DeviceSpecificationSpecType coding system",
        "definition": "The IEEE concept defined in the 11073Type coding element expressed in the DeviceSpecificationSpecType coding system.",
        "comment": "FHIR requires this element to be present IF the production specification being reported is included in the DeviceSpecificationSpecType value set. Currently that is all the possible entries defined in the IEEE 11073 ProductionSpecification attribute. These codes and entries are as follows:\r\nCode                      Description\r\nunspecified            Unspecified Production Specification \r\nserial-number        Serial Number\r\npart-number          Part Number \r\nhardware-revision  Hardware Revision \r\nsoftware-revision   Software Revision \r\nfirmware-revision   Firmware Revision \r\nprotocol-revision    Protocol Revision \r\ngmdn                      Global Medical Device Nomencalture",
        "requirements": "Besides satisfying a system requirement, including these values supports searches for DeviceComponents based upon the DeviceSpecificationSpecType codes. Of course, as of 3.0.1 searches on the DeviceComponent.productionSpecification are not supported but this is to change in the future.",
        "max": "1"
      },
      {
        "id": "DeviceComponent.productionSpecification.specType.coding:fhirCoding.system",
        "path": "DeviceComponent.productionSpecification.specType.coding.system",
        "min": 1,
        "fixedUri": "http://hl7.org/fhir/specification-type"
      },
      {
        "id": "DeviceComponent.productionSpecification.specType.coding:fhirCoding.code",
        "path": "DeviceComponent.productionSpecification.specType.coding.code",
        "definition": "A symbol in the syntax defined by the DeviceSpecificationSpecType system.",
        "comment": "FHIR requires this code if the specType being coded is a member of this value set.",
        "min": 1
      },
      {
        "id": "DeviceComponent.productionSpecification.productionSpec",
        "path": "DeviceComponent.productionSpecification.productionSpec",
        "min": 1
      },
      {
        "id": "DeviceComponent.languageCode",
        "path": "DeviceComponent.languageCode",
        "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 infomration is not available by protocol from the PHD and its use is up to the application"
      }
    ]
  }
}