The characteristics, operational status and capabilities of a medical-related component of a medical device. A PHD is JUST the medical-related component.

For the initial scope, this Device 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.

With 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 multiple specialization support is rare.

The 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.

This entry contains the IEEE EUI-64. If absent (bad device) set to all zeros.

Identifies the system as an IEEE EUI.

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.

The formatting is specified in the IEEE document Guidelines for 64-bit Global Identifier.

To allow the mapping of 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

This entry contains the Bluetooth MAC transport address.

The Bluetooth MAC as an EUI-48 such as 00-E5-DE-AD-77-C3.

Transport addresses are supposed to be unique for a given device.

This entry contains the MAC transport address.

The MAC as an EUI-48 such as 00-E5-DE-AD-77-C8.

Transport addresses are supposed to be unique for a given device.

The manufacturer name as reported in the IEEE 11073-10206 SystemInfo.

The system manufacturer attribute is required by the IEEE 11073-10206 specification

The serial number as reported by the IEEE 11073-10206 SystemInfo.

The serial number is optional in the 11073-10206 specification. The serial number shall be present if the PHD reports it.

The model number as reported by the SystemInfo attribute.

The model number attribute is required by the IEEE 11073-10206 specification

The IEEE 11073-10101 code for the PHD simple MDS.

This value identifies the IEEE 11073-10101 coding system

The code for a Simple MDS indicating that this unit is a personal health device

A human readable display describing the meaning of the MDC code.

It is suggested that this element contain the reference identfier for Simple MDS 'MDC_MOC_VMS_MDS_SIMP'.

There shall be a specialization entry for each specialization reported in the required System-Type-Spec-List attribute. A specialization in this case defines not only what type of measurements the PHD reports but that the PHD reports these measurements according to one of the 11073-114xx specialization standards. Most PHDs support only a single specialization such as the Blood Pressure or Pulse Oximeter specialization.

The specialization.specType comes from the System-Type-Spec-List specialization entry 'type'.

The version of the specialization comes from the System-Type-Spec-List specialization entry. If a PHD supports multiple versions of the same specialization a separate Device.specialization entry is needed where the systemType elements are repeated. If the PHD reports a generic specialization (follows no 114xx specialization but conforms to the 11072-10206 standard, the version is the 10206 protocol version.

There are several versions that are reported from a PHD. Firmware, Hardware, Protocol (internal, not 10206), and Software versions come from the Production-Specification attribute. The Continua version comes from the Reg-Cert-Data-List attribute. Continua compliant PHDs report at least a firmware and Continua version. A separate version entry is needed for each of the versions reported by the PHD.

The currently defined version codes used in this element are as shown in the Table. More than one of these versions may be reported by a PHD. Each version reported by the PHD shall be encoded.

   Description                   CODE             Reference Identifier
   ------------------------------------------------------------------------------------
   Hardware revision            531974            MDC_ID_PROD_SPEC_HW
   Software revision            531975            MDC_ID_PROD_SPEC_SW
   Firmware revision            531976            MDC_ID_PROD_SPEC_FW
   Protocol                     531977            MDC_ID_PROD_SPEC_PROTOCOL
   Continua version             532352            MDC_REG_CERT_DATA_CONTINUA_VERSION
   The Continua version comes from the Continua Reg-Cert-Data-List attribute

For each bit setting reported a BITs value, a bitProperties element is used.

A BITs measurement is a 16 or 32-bit ASN1 BITs value where each bit means something.

One of the capabilities reported in the Mds-Time-Info.mds-time-caps-state or Reg-Cert-Data-List.regulation-status field.

Only set 'event' types need be reported. Both set and cleared 'state' types need to be reported. The regulation status is as state type. All time capabilities are event types

The ASN1 code made from the code and the Mder bit position

The MDC code for the mds-time-caps-state field is 68219. Thus the ASN1 code for the case 'device supports a relative time clock', Mder bit 2, would be 68219.2. For the regulation status field the MDC code is 532354, and only bit 0 is defined. However, the regulated status is when the bit is cleared and the unregulated status is when the bit is set. That choice can be confusing.

It is recommended to display at least the ASN1 name for the given bit meaning

If bit is set, code contains Y if cleared, N

This element represents all those time properties that are a quantity such as the various clock resolutions and synchronization accuracy.

If the PHD reports that one of these given properties are unknown, this element shall not be populated for that property.

The MDC code representing the property

Currently PHDs support the reporting of the time quantities as shown in the Table. More may be added in the future

   Description                        CODE            Reference Identifier
   ------------------------------------------------------------------------------------
   Absolute clock resolution         68222            MDC_TIME_RES_ABS
   Base-offset clock resolution      68226            MDC_TIME_RES_BO
   Relative time resolution          68223            MDC_TIME_RES_REL
   Hi Res relative time resolution   68224            MDC_TIME_RES_REL_HI_RES
   Time sync accuracy                68221            MDC_TIME_SYNC_ACCURACY
   Tick Resolution                   68229            MDC_ATTR_TICK_RES

It is recommended to display at least the MDC reference identifier for the MDC code

The value. All the time fields are scaled to microseconds

The unit code shall use the UCUM system

The UCUM code (for microseconds it is 'us')

This element represents all those properties that are a list of codes. At the moment there is only certified PHD interfaces.

Continua certified PHDs are required to have these entries.

The MDC code representing the property

Currently PHDs support the reporting of one of the coded lists as shown in the Table. More may be added in the future

   Description                CODE    Reference Identifier                           Code System
   -----------------------------------------------------------------------------------------------------------------------------------
Time synchronization      68220    MDC_TIME_SYNC_PROTOCOL
   Certified PHD interfaces  532353   MDC_REG_CERT_DATA_CONTINUA_CERT_DEV_LIST       http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaPHD

It is recommended to display at least the MDC reference identifier for the code

Either the http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaPHD or urn:iso:std:iso:11073:10101 code systems

One of the Continua interface certification codes

The characteristics, operational status and capabilities of a medical-related component of a medical device. A PHD is JUST the medical-related component.

For the initial scope, this Device 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.

With 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 multiple specialization support is rare.

A reference to a set of rules that were followed when the resource was constructed, and which must be understood when processing the content. Often, this is a reference to an implementation guide that defines the special rules along with other profiles etc.

Asserting this rule set restricts the content to be only understood by a limited set of trading partners. This inherently limits the usefulness of the data in the long term. However, the existing health eco-system is highly fractured, and not yet ready to define, collect, and exchange data in a generally computable sense. Wherever possible, implementers and/or specification writers should avoid using this element. Often, when used, the URL is a reference to an implementation guide that defines these special rules as part of it's narrative along with other profiles, value sets, etc.

May be used to represent additional information that is not part of the basic definition of the resource and that modifies the understanding of the element that contains it and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer is allowed to define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.

The 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.

The barcode string from a barcode present on a device label or package may identify the instance, include names given to the device in local usage, or may identify the type of device. If the identifier identifies the type of device, Device.type element should be used.

This entry contains the IEEE EUI-64. If absent (bad device) set to all zeros.

The barcode string from a barcode present on a device label or package may identify the instance, include names given to the device in local usage, or may identify the type of device. If the identifier identifies the type of device, Device.type element should be used.

The purpose of this identifier.

Applications can assume that an identifier is permanent unless it explicitly says that it is temporary.

Allows the appropriate identifier for a particular context of use to be selected from among a set of identifiers.

A coded type for the identifier that can be used to determine which identifier to use for a specific purpose.

This element deals only with general categories of identifiers. It SHOULD not be used for codes that correspond 1..1 with the Identifier.system. Some identifiers may fall into multiple categories due to common usage. Where the system is known, a type is unnecessary because the type is always part of the system definition. However systems often need to handle identifiers where the system is not known. There is not a 1:1 relationship between type and system, since many different systems have the same type.

Allows users to make use of identifiers when the identifier system is not known.

A reference to a code defined by a terminology system.

Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.

Allows for alternative encodings within a code system, and translations to other code systems.

The identification of the code system that defines the meaning of the symbol in the code.

The URI may be an OID (urn:oid:...) or a UUID (urn:uuid:...). OIDs and UUIDs SHALL be references to the HL7 OID registry. Otherwise, the URI should come from HL7's list of FHIR defined special URIs or it should reference to some definition that establishes the system clearly and unambiguously.

Need to be unambiguous about the source of the definition of the symbol.

A symbol in syntax defined by the system. The symbol may be a predefined code or an expression in a syntax defined by the coding system (e.g. post-coordination).

Need to refer to a particular code in the system.

Identifies the system as an IEEE EUI.

Identifier.system is always case sensitive.

There are many sets of identifiers. To perform matching of two identifiers, we need to know what set we're dealing with. The system identifies a particular set of unique identifiers.

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.

The formatting is specified in the IEEE document Guidelines for 64-bit Global Identifier.

To allow the mapping of 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

This entry contains the Bluetooth MAC transport address.

The barcode string from a barcode present on a device label or package may identify the instance, include names given to the device in local usage, or may identify the type of device. If the identifier identifies the type of device, Device.type element should be used.

The purpose of this identifier.

Applications can assume that an identifier is permanent unless it explicitly says that it is temporary.

Allows the appropriate identifier for a particular context of use to be selected from among a set of identifiers.

A coded type for the identifier that can be used to determine which identifier to use for a specific purpose.

This element deals only with general categories of identifiers. It SHOULD not be used for codes that correspond 1..1 with the Identifier.system. Some identifiers may fall into multiple categories due to common usage. Where the system is known, a type is unnecessary because the type is always part of the system definition. However systems often need to handle identifiers where the system is not known. There is not a 1:1 relationship between type and system, since many different systems have the same type.

Allows users to make use of identifiers when the identifier system is not known.

A reference to a code defined by a terminology system.

Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.

Allows for alternative encodings within a code system, and translations to other code systems.

The identification of the code system that defines the meaning of the symbol in the code.

The URI may be an OID (urn:oid:...) or a UUID (urn:uuid:...). OIDs and UUIDs SHALL be references to the HL7 OID registry. Otherwise, the URI should come from HL7's list of FHIR defined special URIs or it should reference to some definition that establishes the system clearly and unambiguously.

Need to be unambiguous about the source of the definition of the symbol.

A symbol in syntax defined by the system. The symbol may be a predefined code or an expression in a syntax defined by the coding system (e.g. post-coordination).

Need to refer to a particular code in the system.

Establishes the namespace for the value - that is, a URL that describes a set values that are unique.

Identifier.system is always case sensitive.

There are many sets of identifiers. To perform matching of two identifiers, we need to know what set we're dealing with. The system identifies a particular set of unique identifiers.

The Bluetooth MAC as an EUI-48 such as 00-E5-DE-AD-77-C3.

Transport addresses are supposed to be unique for a given device.

This entry contains the MAC transport address.

The barcode string from a barcode present on a device label or package may identify the instance, include names given to the device in local usage, or may identify the type of device. If the identifier identifies the type of device, Device.type element should be used.

The purpose of this identifier.

Applications can assume that an identifier is permanent unless it explicitly says that it is temporary.

Allows the appropriate identifier for a particular context of use to be selected from among a set of identifiers.

A coded type for the identifier that can be used to determine which identifier to use for a specific purpose.

This element deals only with general categories of identifiers. It SHOULD not be used for codes that correspond 1..1 with the Identifier.system. Some identifiers may fall into multiple categories due to common usage. Where the system is known, a type is unnecessary because the type is always part of the system definition. However systems often need to handle identifiers where the system is not known. There is not a 1:1 relationship between type and system, since many different systems have the same type.

Allows users to make use of identifiers when the identifier system is not known.

A reference to a code defined by a terminology system.

Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.

Allows for alternative encodings within a code system, and translations to other code systems.

The identification of the code system that defines the meaning of the symbol in the code.

The URI may be an OID (urn:oid:...) or a UUID (urn:uuid:...). OIDs and UUIDs SHALL be references to the HL7 OID registry. Otherwise, the URI should come from HL7's list of FHIR defined special URIs or it should reference to some definition that establishes the system clearly and unambiguously.

Need to be unambiguous about the source of the definition of the symbol.

A symbol in syntax defined by the system. The symbol may be a predefined code or an expression in a syntax defined by the coding system (e.g. post-coordination).

Need to refer to a particular code in the system.

Establishes the namespace for the value - that is, a URL that describes a set values that are unique.

Identifier.system is always case sensitive.

There are many sets of identifiers. To perform matching of two identifiers, we need to know what set we're dealing with. The system identifies a particular set of unique identifiers.

The MAC as an EUI-48 such as 00-E5-DE-AD-77-C8.

Transport addresses are supposed to be unique for a given device.

Status of the Device availability.

This element is labeled as a modifier because the status contains the codes inactive and entered-in-error that mark the device (record)as not currently valid.

The availability status of the device.

The manufacturer name as reported in the IEEE 11073-10206 SystemInfo.

The system manufacturer attribute is required by the IEEE 11073-10206 specification

The serial number as reported by the IEEE 11073-10206 SystemInfo.

The serial number is optional in the 11073-10206 specification. The serial number shall be present if the PHD reports it.

The model number as reported by the SystemInfo attribute.

The model number attribute is required by the IEEE 11073-10206 specification

The kind or type of device.

Codes to identify medical devices.

A reference to a code defined by a terminology system.

Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.

Allows for alternative encodings within a code system, and translations to other code systems.

The IEEE 11073-10101 code for the PHD simple MDS.

Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.

Allows for alternative encodings within a code system, and translations to other code systems.

This value identifies the IEEE 11073-10101 coding system

The URI may be an OID (urn:oid:...) or a UUID (urn:uuid:...). OIDs and UUIDs SHALL be references to the HL7 OID registry. Otherwise, the URI should come from HL7's list of FHIR defined special URIs or it should reference to some definition that establishes the system clearly and unambiguously.

Need to be unambiguous about the source of the definition of the symbol.

The code for a Simple MDS indicating that this unit is a personal health device

Need to refer to a particular code in the system.

A human readable display describing the meaning of the MDC code.

It is suggested that this element contain the reference identfier for Simple MDS 'MDC_MOC_VMS_MDS_SIMP'.

The codes from the terminologies do not always capture the correct meaning with all the nuances of the human using them, or sometimes there is no appropriate code at all. In these cases, the text is used to capture the full meaning of the source.

The capabilities supported on a device, the standards to which the device conforms for a particular purpose, and used for the communication.

There shall be a specialization entry for each specialization reported in the required System-Type-Spec-List attribute. A specialization in this case defines not only what type of measurements the PHD reports but that the PHD reports these measurements according to one of the 11073-114xx specialization standards. Most PHDs support only a single specialization such as the Blood Pressure or Pulse Oximeter specialization.

May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.

The standard that is used to operate and communicate.

The specialization.specType comes from the System-Type-Spec-List specialization entry 'type'.

A reference to a code defined by a terminology system.

Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.

Allows for alternative encodings within a code system, and translations to other code systems.

A reference to a code defined by a terminology system.

Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.

Allows for alternative encodings within a code system, and translations to other code systems.

The identification of the code system that defines the meaning of the symbol in the code.

The URI may be an OID (urn:oid:...) or a UUID (urn:uuid:...). OIDs and UUIDs SHALL be references to the HL7 OID registry. Otherwise, the URI should come from HL7's list of FHIR defined special URIs or it should reference to some definition that establishes the system clearly and unambiguously.

Need to be unambiguous about the source of the definition of the symbol.

A symbol in syntax defined by the system. The symbol may be a predefined code or an expression in a syntax defined by the coding system (e.g. post-coordination).

Need to refer to a particular code in the system.

The version of the standard that is used to operate and communicate.

The version of the specialization comes from the System-Type-Spec-List specialization entry. If a PHD supports multiple versions of the same specialization a separate Device.specialization entry is needed where the systemType elements are repeated. If the PHD reports a generic specialization (follows no 114xx specialization but conforms to the 11072-10206 standard, the version is the 10206 protocol version.

The actual design of the device or software version running on the device.

There are several versions that are reported from a PHD. Firmware, Hardware, Protocol (internal, not 10206), and Software versions come from the Production-Specification attribute. The Continua version comes from the Reg-Cert-Data-List attribute. Continua compliant PHDs report at least a firmware and Continua version. A separate version entry is needed for each of the versions reported by the PHD.

May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.

The type of the device version, e.g. manufacturer, approved, internal.

A reference to a code defined by a terminology system.

Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.

Allows for alternative encodings within a code system, and translations to other code systems.

A reference to a code defined by a terminology system.

Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.

Allows for alternative encodings within a code system, and translations to other code systems.

The identification of the code system that defines the meaning of the symbol in the code.

The URI may be an OID (urn:oid:...) or a UUID (urn:uuid:...). OIDs and UUIDs SHALL be references to the HL7 OID registry. Otherwise, the URI should come from HL7's list of FHIR defined special URIs or it should reference to some definition that establishes the system clearly and unambiguously.

Need to be unambiguous about the source of the definition of the symbol.

A symbol in syntax defined by the system. The symbol may be a predefined code or an expression in a syntax defined by the coding system (e.g. post-coordination).

The currently defined version codes used in this element are as shown in the Table. More than one of these versions may be reported by a PHD. Each version reported by the PHD shall be encoded.

   Description                   CODE             Reference Identifier
   ------------------------------------------------------------------------------------
   Hardware revision            531974            MDC_ID_PROD_SPEC_HW
   Software revision            531975            MDC_ID_PROD_SPEC_SW
   Firmware revision            531976            MDC_ID_PROD_SPEC_FW
   Protocol                     531977            MDC_ID_PROD_SPEC_PROTOCOL
   Continua version             532352            MDC_REG_CERT_DATA_CONTINUA_VERSION
   The Continua version comes from the Continua Reg-Cert-Data-List attribute

Need to refer to a particular code in the system.

The version text.

The actual configuration settings of a device as it actually operates, e.g., regulation status, time properties.

May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.

Code that specifies the property DeviceDefinitionPropetyCode (Extensible).

For each bit setting reported a BITs value, a bitProperties element is used.

A BITs measurement is a 16 or 32-bit ASN1 BITs value where each bit means something.

May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.

One of the capabilities reported in the Mds-Time-Info.mds-time-caps-state or Reg-Cert-Data-List.regulation-status field.

Only set 'event' types need be reported. Both set and cleared 'state' types need to be reported. The regulation status is as state type. All time capabilities are event types

A reference to a code defined by a terminology system.

Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.

Allows for alternative encodings within a code system, and translations to other code systems.

The identification of the code system that defines the meaning of the symbol in the code.

The URI may be an OID (urn:oid:...) or a UUID (urn:uuid:...). OIDs and UUIDs SHALL be references to the HL7 OID registry. Otherwise, the URI should come from HL7's list of FHIR defined special URIs or it should reference to some definition that establishes the system clearly and unambiguously.

Need to be unambiguous about the source of the definition of the symbol.

The ASN1 code made from the code and the Mder bit position

The MDC code for the mds-time-caps-state field is 68219. Thus the ASN1 code for the case 'device supports a relative time clock', Mder bit 2, would be 68219.2. For the regulation status field the MDC code is 532354, and only bit 0 is defined. However, the regulated status is when the bit is cleared and the unregulated status is when the bit is set. That choice can be confusing.

Need to refer to a particular code in the system.

It is recommended to display at least the ASN1 name for the given bit meaning

Very often the text is the same as a displayName of one of the codings.

The codes from the terminologies do not always capture the correct meaning with all the nuances of the human using them, or sometimes there is no appropriate code at all. In these cases, the text is used to capture the full meaning of the source.

Property value as a quantity.

Property value as a code, e.g., NTP4 (synced to NTP).

A reference to a code defined by a terminology system.

Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.

Allows for alternative encodings within a code system, and translations to other code systems.

A reference to a code defined by a terminology system.

Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.

Allows for alternative encodings within a code system, and translations to other code systems.

The identification of the code system that defines the meaning of the symbol in the code.

The URI may be an OID (urn:oid:...) or a UUID (urn:uuid:...). OIDs and UUIDs SHALL be references to the HL7 OID registry. Otherwise, the URI should come from HL7's list of FHIR defined special URIs or it should reference to some definition that establishes the system clearly and unambiguously.

Need to be unambiguous about the source of the definition of the symbol.

If bit is set, code contains Y if cleared, N

Need to refer to a particular code in the system.

This element represents all those time properties that are a quantity such as the various clock resolutions and synchronization accuracy.

If the PHD reports that one of these given properties are unknown, this element shall not be populated for that property.

May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.

Code that specifies the property DeviceDefinitionPropetyCode (Extensible).

A reference to a code defined by a terminology system.

Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.

Allows for alternative encodings within a code system, and translations to other code systems.

A reference to a code defined by a terminology system.

Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.

Allows for alternative encodings within a code system, and translations to other code systems.

The identification of the code system that defines the meaning of the symbol in the code.

The URI may be an OID (urn:oid:...) or a UUID (urn:uuid:...). OIDs and UUIDs SHALL be references to the HL7 OID registry. Otherwise, the URI should come from HL7's list of FHIR defined special URIs or it should reference to some definition that establishes the system clearly and unambiguously.

Need to be unambiguous about the source of the definition of the symbol.

The MDC code representing the property

Currently PHDs support the reporting of the time quantities as shown in the Table. More may be added in the future

   Description                        CODE            Reference Identifier
   ------------------------------------------------------------------------------------
   Absolute clock resolution         68222            MDC_TIME_RES_ABS
   Base-offset clock resolution      68226            MDC_TIME_RES_BO
   Relative time resolution          68223            MDC_TIME_RES_REL
   Hi Res relative time resolution   68224            MDC_TIME_RES_REL_HI_RES
   Time sync accuracy                68221            MDC_TIME_SYNC_ACCURACY
   Tick Resolution                   68229            MDC_ATTR_TICK_RES

Need to refer to a particular code in the system.

It is recommended to display at least the MDC reference identifier for the MDC code

Very often the text is the same as a displayName of one of the codings.

The codes from the terminologies do not always capture the correct meaning with all the nuances of the human using them, or sometimes there is no appropriate code at all. In these cases, the text is used to capture the full meaning of the source.

The value. All the time fields are scaled to microseconds

How the value should be understood and represented - whether the actual value is greater or less than the stated value due to measurement issues; e.g. if the comparator is "<" , then the real value is < stated value.

Need a framework for handling measures where the value is <5ug/L or >400mg/L due to the limitations of measuring methodology.

The unit code shall use the UCUM system

Need to know the system that defines the coded form of the unit.

The UCUM code (for microseconds it is 'us')

The preferred system is UCUM, but SNOMED CT can also be used (for customary units) or ISO 4217 for currency. The context of use may additionally require a code from a particular system.

Need a computable form of the unit that is fixed across all forms. UCUM provides this for quantities, but SNOMED CT provides many units of interest.

Property value as a code, e.g., NTP4 (synced to NTP).

This element represents all those properties that are a list of codes. At the moment there is only certified PHD interfaces.

Continua certified PHDs are required to have these entries.

May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.

Code that specifies the property DeviceDefinitionPropetyCode (Extensible).

A reference to a code defined by a terminology system.

Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.

Allows for alternative encodings within a code system, and translations to other code systems.

The identification of the code system that defines the meaning of the symbol in the code.

The URI may be an OID (urn:oid:...) or a UUID (urn:uuid:...). OIDs and UUIDs SHALL be references to the HL7 OID registry. Otherwise, the URI should come from HL7's list of FHIR defined special URIs or it should reference to some definition that establishes the system clearly and unambiguously.

Need to be unambiguous about the source of the definition of the symbol.

The MDC code representing the property

Currently PHDs support the reporting of one of the coded lists as shown in the Table. More may be added in the future

   Description                CODE    Reference Identifier                           Code System
   -----------------------------------------------------------------------------------------------------------------------------------
Time synchronization      68220    MDC_TIME_SYNC_PROTOCOL
   Certified PHD interfaces  532353   MDC_REG_CERT_DATA_CONTINUA_CERT_DEV_LIST       http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaPHD

Need to refer to a particular code in the system.

It is recommended to display at least the MDC reference identifier for the code

Very often the text is the same as a displayName of one of the codings.

The codes from the terminologies do not always capture the correct meaning with all the nuances of the human using them, or sometimes there is no appropriate code at all. In these cases, the text is used to capture the full meaning of the source.

Property value as a quantity.

Property value as a code, e.g., NTP4 (synced to NTP).

A reference to a code defined by a terminology system.

Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.

Allows for alternative encodings within a code system, and translations to other code systems.

Either the http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaPHD or urn:iso:std:iso:11073:10101 code systems

The URI may be an OID (urn:oid:...) or a UUID (urn:uuid:...). OIDs and UUIDs SHALL be references to the HL7 OID registry. Otherwise, the URI should come from HL7's list of FHIR defined special URIs or it should reference to some definition that establishes the system clearly and unambiguously.

Need to be unambiguous about the source of the definition of the symbol.

One of the Continua interface certification codes

Need to refer to a particular code in the system.

The characteristics, operational status and capabilities of a medical-related component of a medical device. A PHD is JUST the medical-related component.

For the initial scope, this Device 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.

With 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 multiple specialization support is rare.

The logical id of the resource, as used in the URL for the resource. Once assigned, this value never changes.

The only time that a resource does not have an id is when it is being submitted to the server using a create operation.

The metadata about the resource. This is content that is maintained by the infrastructure. Changes to the content might not always be associated with version changes to the resource.

A reference to a set of rules that were followed when the resource was constructed, and which must be understood when processing the content. Often, this is a reference to an implementation guide that defines the special rules along with other profiles etc.

Asserting this rule set restricts the content to be only understood by a limited set of trading partners. This inherently limits the usefulness of the data in the long term. However, the existing health eco-system is highly fractured, and not yet ready to define, collect, and exchange data in a generally computable sense. Wherever possible, implementers and/or specification writers should avoid using this element. Often, when used, the URL is a reference to an implementation guide that defines these special rules as part of it's narrative along with other profiles, value sets, etc.

The base language in which the resource is written.

Language is provided to support indexing and accessibility (typically, services such as text to speech use the language tag). The html language tag in the narrative applies to the narrative. The language tag on the resource may be used to specify the language of other presentations generated from the data in the resource. Not all the content has to be in the base language. The Resource.language should not be assumed to apply to the narrative automatically. If a language is specified, it should it also be specified on the div element in the html (see rules in HTML5 for information about the relationship between xml:lang and the html lang attribute).

IETF language tag

A human-readable narrative that contains a summary of the resource and can be used to represent the content of the resource to a human. The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative. Resource definitions may define what content should be represented in the narrative to ensure clinical safety.

Contained resources do not have narrative. Resources that are not contained SHOULD have a narrative. In some cases, a resource may only have text with little or no additional discrete data (as long as all minOccurs=1 elements are satisfied). This may be necessary for data from legacy systems where information is captured as a "text blob" or where text is additionally entered raw or narrated and encoded information is added later.

These resources do not have an independent existence apart from the resource that contains them - they cannot be identified independently, and nor can they have their own independent transaction scope.

This should never be done when the content can be identified properly, as once identification is lost, it is extremely difficult (and context dependent) to restore it again. Contained resources may have profiles and tags In their meta elements, but SHALL NOT have security labels.

May be used to represent additional information that is not part of the basic definition of the resource. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

May be used to represent additional information that is not part of the basic definition of the resource and that modifies the understanding of the element that contains it and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer is allowed to define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.

The 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.

The barcode string from a barcode present on a device label or package may identify the instance, include names given to the device in local usage, or may identify the type of device. If the identifier identifies the type of device, Device.type element should be used.

This entry contains the IEEE EUI-64. If absent (bad device) set to all zeros.

The barcode string from a barcode present on a device label or package may identify the instance, include names given to the device in local usage, or may identify the type of device. If the identifier identifies the type of device, Device.type element should be used.

Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.

May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

The purpose of this identifier.

Applications can assume that an identifier is permanent unless it explicitly says that it is temporary.

Allows the appropriate identifier for a particular context of use to be selected from among a set of identifiers.

A coded type for the identifier that can be used to determine which identifier to use for a specific purpose.

This element deals only with general categories of identifiers. It SHOULD not be used for codes that correspond 1..1 with the Identifier.system. Some identifiers may fall into multiple categories due to common usage. Where the system is known, a type is unnecessary because the type is always part of the system definition. However systems often need to handle identifiers where the system is not known. There is not a 1:1 relationship between type and system, since many different systems have the same type.