The current mechanism of indicating the standards that a device supports assumes a particular model of a generic standard that has been refined into specializations for specific device types.

In most other cases, a device may comply with a standard which has not been specialized for that device type.

Consider how to indicate that a device conforms with:

• HL7 v2, CDA, or FHIR (or particular implementation guides of each)
• DICOM (or particular DICOM SOP classes)
• IHE profiles (or particular profile/actor/option combinations)
• water or dust ingress protection (IP) standards
• sterilization standards
• electrical standards
• ionizing or electro-magnetic radiation emission or resistance standards
• recycle-ability, ROHS, or similar standards
• Wifi, Bluetooth, ethernet standards (or particular Wifi versions or Bluetooth profiles)

Is this element also intended to be used to indicate operating system compatibility (certified or otherwise) for software?

Is Wifi 802.11g compliance indicated with a 802.11g specialization; or with a Wifi specialization and an 802.11g version?

Although there may be particular "specializations" within the some of these that the device conforms to (e.g. a DICOM SOP class, or an IP code), in other cases the need is simply to indicate conformance with the standard.

I accept that the specialization element and sub-element names and datatypes are unlikely to change, so as to preserve backward compatibility. However, definitions should be refined:

• systemType
  • short: A code that indicates the supported standard
  • definition: A code that indicates the supported standard, standard specialization, or section within a standard, that the device is compliant with.
• version
  • short: version of the standard
  • definition: The specific version (a.k.a, release or revision) of the standard that the device is compliant with. For example, the IEEE 802.11g Wi-Fi specialization is defined in "802.11-2007" and "802.11-2012" versions of the 802.11 standard.
• category
  • cardinality: relax to 0..* to support standards that may cover multiple categories.
  • consider adding "safety" as a category.

Rename the systemType ValueSet to "DeviceStandard", and category ValueSet to "DeviceStandardCategory." Improve definitions of category concepts (e.g., What is a "communication standard"? is Braille a communication standard? Is ANSI Z535 or ISO 3864-2 [Hazardous alert symbols] a communication standard?).

It should be made clear (either in the ValueSet or in systemType comment) how to express compliance with standards other than IEEE 11073 specializations.

Document (in definition? comment?) how to express compliance with a standard but not a particular specialization of the standard. Does there need to be a code within the selected code system to mean "the entire standard"? Do we indicate a code system without a code?

Note that if DICOM SOP classes (expressed as OIDs) are each a specialization, there are specific requirements within FHIR for what system to use for DICOM OIDs.