From 5ddedb6baa9a3857067e1f27b39fb6d272ba1bcb Mon Sep 17 00:00:00 2001 From: Erik Moll Date: Wed, 30 Jul 2025 16:50:34 +0200 Subject: [PATCH] Assigned THO url to ContinuaDeviceIdentifiers code system --- .cspell/custom-dictionary-workspace.txt | 3 +++ input/PhdImplementationGuide.xml | 5 ++--- input/examples/bundle-example-1.json | 6 +++--- .../phd-00601900010E9234.F45EABA80832.json | 6 +++--- .../phd-711000FEFF5F49B0.B0495F001071.json | 4 ++-- .../phd-74E8FFFEFF051C00.001C05FFE874.json | 4 ++-- .../phg-ecde3d4e58532d31.000000000000.json | 6 +++--- input/examples/phg-example.json | 2 +- .../CodeSystem.ContinuaDeviceIdentifiers.fsh | 2 +- input/fsh/StructureDefinition.PhdDevice.fsh | 6 +++--- input/fsh/StructureDefinition.PhgDevice.fsh | 6 +++--- input/fsh/ValueSet.ASN1ClockBits.fsh | 2 +- input/fsh/ValueSet.MDCDeviceIdentifierTypes.fsh | 2 +- input/pagecontent/ContinuaHealthFitnessCodes.md | 17 ----------------- .../ContinuaPersonalAreaNetworkCodes.md | 1 - input/pagecontent/DIMtoFHIRMapping.md | 4 ++-- input/pagecontent/GenericModel.md | 2 +- input/pagecontent/Nomenclaturecodes.md | 2 +- input/pagecontent/ProfileConsumers.md | 10 +++++----- 19 files changed, 37 insertions(+), 53 deletions(-) delete mode 100644 input/pagecontent/ContinuaHealthFitnessCodes.md delete mode 100644 input/pagecontent/ContinuaPersonalAreaNetworkCodes.md diff --git a/.cspell/custom-dictionary-workspace.txt b/.cspell/custom-dictionary-workspace.txt index 5e5f1be..fb56b61 100644 --- a/.cspell/custom-dictionary-workspace.txt +++ b/.cspell/custom-dictionary-workspace.txt @@ -1,4 +1,6 @@ # Custom Dictionary Words +bitstring +bitstrings codeable FHIR LOINC @@ -11,6 +13,7 @@ plethysmograph RTMMS SFLOAT SNOMED +thresholding timestamping UCUM unsynchronized diff --git a/input/PhdImplementationGuide.xml b/input/PhdImplementationGuide.xml index 05346ea..8344703 100644 --- a/input/PhdImplementationGuide.xml +++ b/input/PhdImplementationGuide.xml @@ -627,10 +627,9 @@ In this example there are only xml structure definitions, value sets, code syste - + - + - diff --git a/input/examples/bundle-example-1.json b/input/examples/bundle-example-1.json index 3ec1aae..16aeb65 100644 --- a/input/examples/bundle-example-1.json +++ b/input/examples/bundle-example-1.json @@ -58,7 +58,7 @@ "type": { "coding": [ { - "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers", + "system": "http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers", "code": "SYSID", "display": "IEEE 11073 System Identifier" } @@ -333,7 +333,7 @@ "type": { "coding": [ { - "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers", + "system": "http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers", "code": "SYSID", "display": "IEEE 11073 System Identifier" } @@ -346,7 +346,7 @@ "type": { "coding": [ { - "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers", + "system": "http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers", "code": "BTMAC", "display": "Bluetooth MAC Address" } diff --git a/input/examples/phd-00601900010E9234.F45EABA80832.json b/input/examples/phd-00601900010E9234.F45EABA80832.json index 4507e89..78269cf 100644 --- a/input/examples/phd-00601900010E9234.F45EABA80832.json +++ b/input/examples/phd-00601900010E9234.F45EABA80832.json @@ -11,7 +11,7 @@ "type": { "coding": [ { - "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers", + "system": "http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers", "code": "SYSID" } ] @@ -23,7 +23,7 @@ "type": { "coding": [ { - "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers", + "system": "http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers", "code": "BTMAC" } ] @@ -153,7 +153,7 @@ "type": { "coding": [ { - "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers", + "system": "http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers", "code": "USB" } ] diff --git a/input/examples/phd-711000FEFF5F49B0.B0495F001071.json b/input/examples/phd-711000FEFF5F49B0.B0495F001071.json index fdda74f..7075e06 100644 --- a/input/examples/phd-711000FEFF5F49B0.B0495F001071.json +++ b/input/examples/phd-711000FEFF5F49B0.B0495F001071.json @@ -11,7 +11,7 @@ "type": { "coding": [ { - "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers", + "system": "http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers", "code": "SYSID" } ] @@ -23,7 +23,7 @@ "type": { "coding": [ { - "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers", + "system": "http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers", "code": "BTMAC" } ] diff --git a/input/examples/phd-74E8FFFEFF051C00.001C05FFE874.json b/input/examples/phd-74E8FFFEFF051C00.001C05FFE874.json index 2f1f357..01343fb 100644 --- a/input/examples/phd-74E8FFFEFF051C00.001C05FFE874.json +++ b/input/examples/phd-74E8FFFEFF051C00.001C05FFE874.json @@ -11,7 +11,7 @@ "type": { "coding": [ { - "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers", + "system": "http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers", "code": "SYSID", "display": "IEEE 11073 System Identifier" } @@ -24,7 +24,7 @@ "type": { "coding": [ { - "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers", + "system": "http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers", "code": "BTMAC", "display": "Bluetooth MAC address" } diff --git a/input/examples/phg-ecde3d4e58532d31.000000000000.json b/input/examples/phg-ecde3d4e58532d31.000000000000.json index 98a6a09..bb9ec4f 100644 --- a/input/examples/phg-ecde3d4e58532d31.000000000000.json +++ b/input/examples/phg-ecde3d4e58532d31.000000000000.json @@ -11,7 +11,7 @@ "type": { "coding": [ { - "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers", + "system": "http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers", "code": "SYSID" } ] @@ -23,7 +23,7 @@ "type": { "coding": [ { - "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers", + "system": "http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers", "code": "BTMAC" } ] @@ -35,7 +35,7 @@ "type": { "coding": [ { - "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers", + "system": "http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers", "code": "ETHMAC" } ] diff --git a/input/examples/phg-example.json b/input/examples/phg-example.json index 6ba285f..c2cda16 100644 --- a/input/examples/phg-example.json +++ b/input/examples/phg-example.json @@ -11,7 +11,7 @@ "type": { "coding": [ { - "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers", + "system": "http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers", "code": "SYSID" } ] diff --git a/input/fsh/CodeSystem.ContinuaDeviceIdentifiers.fsh b/input/fsh/CodeSystem.ContinuaDeviceIdentifiers.fsh index 1a2c6fa..ab59e1d 100644 --- a/input/fsh/CodeSystem.ContinuaDeviceIdentifiers.fsh +++ b/input/fsh/CodeSystem.ContinuaDeviceIdentifiers.fsh @@ -3,7 +3,7 @@ Id: ContinuaDeviceIdentifiers Title: "Continua Device Identifiers" Description: "Codes used to describe the Device (PHD or PHG) Identifiers, such as the system id or Bluetooth Address. More codes maybe added to this list in the future." * ^meta.profile = "http://hl7.org/fhir/StructureDefinition/shareablecodesystem" -* ^url = "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers" +* ^url = "http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers" * ^version = "current" // * ^status = #draft * ^experimental = false diff --git a/input/fsh/StructureDefinition.PhdDevice.fsh b/input/fsh/StructureDefinition.PhdDevice.fsh index f1b00e1..19bb8f5 100644 --- a/input/fsh/StructureDefinition.PhdDevice.fsh +++ b/input/fsh/StructureDefinition.PhdDevice.fsh @@ -28,7 +28,7 @@ Description: "Profile for the Device Resource for a PHD" * ^definition = "This entry contains the IEEE EUI-64." * ^alias = "11073-10206 System id" * type 1.. - * type = http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers#SYSID + * type = http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers#SYSID * ^short = "Required IEEE 11073-10206 System Id code system coding" * system 1.. * system = "urn:oid:1.2.840.10004.1.1.1.0.0.1.0.0.1.2680" (exactly) @@ -42,7 +42,7 @@ Description: "Profile for the Device Resource for a PHD" * ^definition = "This entry contains the Bluetooth MAC transport address." * ^alias = "Bluetooth MAC Transport address" * type 1.. - * type = http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers#BTMAC + * type = http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers#BTMAC * ^short = "Required Bluetooth MAC address code system coding" * system 1.. * system = "http://hl7.org/fhir/sid/eui-48/bluetooth" (exactly) @@ -53,7 +53,7 @@ Description: "Profile for the Device Resource for a PHD" * ^definition = "This entry contains the MAC transport address." * ^alias = "MAC Transport address" * type 1.. - * type = http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers#ETHMAC + * type = http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers#ETHMAC * ^short = "Required Ethernet MAC address code system coding" * system 1.. * system = "http://hl7.org/fhir/sid/eui-48/ethernet" (exactly) diff --git a/input/fsh/StructureDefinition.PhgDevice.fsh b/input/fsh/StructureDefinition.PhgDevice.fsh index b211d3b..b06f166 100644 --- a/input/fsh/StructureDefinition.PhgDevice.fsh +++ b/input/fsh/StructureDefinition.PhgDevice.fsh @@ -27,7 +27,7 @@ Description: "Profile for the Device Resource for a PHG" * ^definition = "This entry contains the IEEE EUI-64." * ^alias = "11073-10206 System id" * type 1.. - * type = http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers#SYSID + * type = http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers#SYSID * ^short = "Required IEEE 11073-10206 System Id code system coding" * system 1.. * system = "urn:oid:1.2.840.10004.1.1.1.0.0.1.0.0.1.2680" (exactly) @@ -41,7 +41,7 @@ Description: "Profile for the Device Resource for a PHG" * ^definition = "This entry contains the Bluetooth MAC transport address." * ^alias = "Bluetooth MAC Transport address" * type 1.. - * type = http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers#BTMAC + * type = http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers#BTMAC * ^short = "Required Bluetooth MAC address code system coding" * system 1.. * system = "http://hl7.org/fhir/sid/eui-48/bluetooth" (exactly) @@ -52,7 +52,7 @@ Description: "Profile for the Device Resource for a PHG" * ^definition = "This entry contains the MAC transport address." * ^alias = "MAC Transport address" * type 1.. - * type = http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers#ETHMAC + * type = http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers#ETHMAC * ^short = "Required Ethernet MAC address code system coding" * system 1.. * system = "http://hl7.org/fhir/sid/eui-48/ethernet" (exactly) diff --git a/input/fsh/ValueSet.ASN1ClockBits.fsh b/input/fsh/ValueSet.ASN1ClockBits.fsh index 21fc01c..15642ad 100644 --- a/input/fsh/ValueSet.ASN1ClockBits.fsh +++ b/input/fsh/ValueSet.ASN1ClockBits.fsh @@ -3,7 +3,7 @@ Id: ASN1ClockBits Title: "ANS1ToHL7 codes defined for Boolean Clock attributes" Description: "ValueSet for the ANS1ToHL7 codes that are not derived from enumeration measurements." * ^meta.profile = "http://hl7.org/fhir/StructureDefinition/shareablevalueset" -* ^url = "http://terminology.hl7.org/ValueSet/ASN1ClockBits" +* ^url = "http://hl7.org/fhir/uv/phd/ValueSet/ASN1ClockBits" * ^version = "current" // * ^status = #draft * ^experimental = false diff --git a/input/fsh/ValueSet.MDCDeviceIdentifierTypes.fsh b/input/fsh/ValueSet.MDCDeviceIdentifierTypes.fsh index 12cafa9..373d215 100644 --- a/input/fsh/ValueSet.MDCDeviceIdentifierTypes.fsh +++ b/input/fsh/ValueSet.MDCDeviceIdentifierTypes.fsh @@ -9,4 +9,4 @@ Description: "ValueSet for the MDC Device Identifier Types" * ^experimental = false * ^date = "2021-09-25" * ^publisher = "Health Level Seven International (Devices Work Group)" -* include codes from system http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers \ No newline at end of file +* include codes from system http://terminology.hl7.org/CodeSystem/ContinuaDeviceIdentifiers \ No newline at end of file diff --git a/input/pagecontent/ContinuaHealthFitnessCodes.md b/input/pagecontent/ContinuaHealthFitnessCodes.md deleted file mode 100644 index 2246f0a..0000000 --- a/input/pagecontent/ContinuaHealthFitnessCodes.md +++ /dev/null @@ -1,17 +0,0 @@ -These codes are used to express the Health and Fitness interfaces. - - - -|Health & Fitness Device Class| Health and Fitness interface code| Reference name| -|- -|PCD-01 web services| 0 |observation-upload-soap| -|Consent enabled PCD-01 web service| 1 |consent-enabled-soap| -|Capability exchange| 2 |capabilities| -|PCD-01 upload using hData| 3 |observation-upload-hdata| -|Consent enabled PCD-01 using hData| 4 |consent-enabled-hdata| -|Questionnaire CDA| 5 |questionnaire| -|Authenticated Persistent Sessions| 6 |aps| -|FHIR resource upload| 7 |observation-upload-fhir| \ No newline at end of file diff --git a/input/pagecontent/ContinuaPersonalAreaNetworkCodes.md b/input/pagecontent/ContinuaPersonalAreaNetworkCodes.md deleted file mode 100644 index 3157668..0000000 --- a/input/pagecontent/ContinuaPersonalAreaNetworkCodes.md +++ /dev/null @@ -1 +0,0 @@ -This page is empty and can be removed... diff --git a/input/pagecontent/DIMtoFHIRMapping.md b/input/pagecontent/DIMtoFHIRMapping.md index 9fa8e89..55118b2 100644 --- a/input/pagecontent/DIMtoFHIRMapping.md +++ b/input/pagecontent/DIMtoFHIRMapping.md @@ -1,7 +1,7 @@ In the IEEE 11073-10206 Abstract Content Model (ACOM), two primary classes are relevant for data upload: the System object and the Observation object. The System object describes the overall device, including its characteristics and capabilities. The Observation object represents individual measurements or events reported by the device. A single PHD will have one System object and will generate multiple Observation objects, each corresponding to a specific measurement or event. -Observation objects in ACOM can represent different types of measurements, including numeric values, enumerated (coded) values, bitfields (for multiple simultaneous states or events), strings, and sample arrays (for periodic data such as waveforms). Numeric observations cover scalar measurements, enumerated observations represent values from a defined set, bitfield observations capture multiple boolean states, and sample arrays represent sequences of numeric values over time. +Observation objects in ACOM can represent different types of measurements, including numeric values, enumerated (coded) values, bitstrings (for multiple simultaneous states or events), strings, and sample arrays (for periodic data such as waveforms). Numeric observations cover scalar measurements, enumerated observations represent values from a defined set, bitstring observations capture multiple boolean states, and sample arrays represent sequences of numeric values over time. The static attributes of the System object are mapped to the FHIR Device resource, while the measurement-related attributes of the Observation objects are mapped to FHIR Observation resources. @@ -14,7 +14,7 @@ The IEEE 11073-10206 Observation Model supports the following measurement values - **Discrete values**: Discrete values are used when the measurements are described by a finite set of options such as the meal context of a glucose measurement. The options might be one of breakfast, lunch, dinner, snack, fasting, etc. A code is used for each option. Discrete values can come as single event, multiple concurrent events or as multiple concurrent boolean state or events. - **Single Event value**: Single discrete values are mapped to `Observation.valueCodeableConcept` elements. - **Multiple Event value**: Multiple discrete values are mapped to multiple Observations each with a `Observation.valueCodeableConcept` elements. - - **Multiple Boolean Event/State values**: Also known as bitsrings. Bitstringss values are discrete measurements where each bit of an integer represents an event or state. An event would be something like 'marginal signal' in a pulse oximeter. An event is only of interest when it occurs and the bit is set when the event occurs. A state, on the other hand, would be something like 'averaging-on' or 'averaging-off'. Both settings of a state are of interest. Bitstrings are used when multiple events and/or states can occur simultaneously. The mapping of bitstring values uses the [ASN1 To HL7 code system](CodeSystem-ASN1ToHL7.html) where each bit position is mapped to a code. Each code is mapped to an `Observation.component.code` element and the bit setting is mapped to a `Observation.component.valueBoolean` element. + - **Multiple Boolean Event/State values**: Also known as bitstrings. Bitstrings values are discrete measurements where each bit of an integer represents an event or state. An event would be something like 'marginal signal' in a pulse oximeter. An event is only of interest when it occurs and the bit is set when the event occurs. A state, on the other hand, would be something like 'averaging-on' or 'averaging-off'. Both settings of a state are of interest. Bitstrings are used when multiple events and/or states can occur simultaneously. The mapping of bitstring values uses the [ASN1 To HL7 code system](CodeSystem-ASN1ToHL7.html) where each bit position is mapped to a code. Each code is mapped to an `Observation.component.code` element and the bit setting is mapped to a `Observation.component.valueBoolean` element. - **String values**: String values are just that; a line of arbitrary text. These rarely used values cannot be generically processed by a machine but are only meant for display. An example of such a measurement would be the program name of a workout on a piece of cardio equipment at a gym. String values are mapped to `Observation.valueString` elements. - **Sample Array values**: Sequences of periodic numeric values. These are used to report waveform traces of a given frequency such as 1000 samples per second. An example of such a measurement would be a digitized ECG trace. Sample array values are mapped to `Observation.valueSampledData` elements. - **Compound values**: Compound values are measurements that need more than one value to describe, such as the x, y and z components of an acceleration or the systolic, diastolic, and MAP components of a blood pressure. Each sub-value is mapped to an `Observation.component` element. Each component comes with a type and a value. diff --git a/input/pagecontent/GenericModel.md b/input/pagecontent/GenericModel.md index 3bc6df5..81d59b9 100644 --- a/input/pagecontent/GenericModel.md +++ b/input/pagecontent/GenericModel.md @@ -6,5 +6,5 @@ This Implementation Guide specifies how one maps the IEEE 11073-10206 ACOM objec In the IEEE 11073-10206 Abstract information Content Model (ACOM), IEEE 11073-10101 nomenclature codes are used to indicate what the items are. Thus, a reader of FHIR resources mapped from these ACOM objects can decode any of these resources if it knows what the codes are. If a future device is deployed the reader will only need an update of its code dictionary to interpret the resource. A PHG uploader will not even need to update its dictionary to perform the mapping to FHIR as the codes are provided by the PHD through protocol. These features eliminate the need for remote updating and/or servicing of PHGs when new IEEE 11073-10206 ACOM PHDs are used. -Note -- IEEE 11073-10206 ACOM does not define a protocol, but requires protocols that support it to support a representation of the objects defined in the model. The Bluetooth SIG Generic Health Sensor Profile (GHSP) defines an ACOM compliant protocol. +Note -- IEEE 11073-10206 ACOM does not define a protocol, but requires protocols that support it to support a representation of the objects defined in the model. The Bluetooth SIG Generic Health Sensor (GHS) Profile defines an ACOM compliant protocol. diff --git a/input/pagecontent/Nomenclaturecodes.md b/input/pagecontent/Nomenclaturecodes.md index dda601c..5d0ba93 100644 --- a/input/pagecontent/Nomenclaturecodes.md +++ b/input/pagecontent/Nomenclaturecodes.md @@ -32,7 +32,7 @@ This means, following the mapping above, that the `Observation.code` element is * `Observation.code.coding.display` optional * `Observation.code.text` optional -If the code matches one of the [FHIR observation-vitalsigns codes]({{ site.data.fhir.path }}observation-vitalsigns.html), the corresponding LOINC code shall be present in an additional coding element. +If the Type corresponds to one of the [FHIR Observation Vital Signs Profiles]({{ site.data.fhir.path }}observation-vitalsigns.html), the corresponding LOINC code shall be present in an additional coding element. If the application wishes to transcode the MDC code into other coding systems the application is free to do so but: * the MDC code shall be present in a coding element, diff --git a/input/pagecontent/ProfileConsumers.md b/input/pagecontent/ProfileConsumers.md index fdb5f71..751a23e 100644 --- a/input/pagecontent/ProfileConsumers.md +++ b/input/pagecontent/ProfileConsumers.md @@ -230,20 +230,20 @@ An example of a coded measurement is a meal context in a glucose monitor: This measurement indicates that the glucose concentration measurement was taken after a meal. -### Measurement Values that are Events or States +### Measurement Values that are sets of Events or States PHDs support a measurement value type that indicate a set of states or events, for example, an independent living monitor may be surveilling an elderly patient's room and report its current state 'door closed', 'window closed', 'climate control on', 'patient in room', and 'lights off'. The report may have been triggered by an event like 'patient entered room'. (There is no such measurement type as a current room state but it illustrates the concept.) PHDs have an efficient way to package such reports into a single integer. This type of reporting is done when more than one state and/or event can occur simultaneously. In order to understand such a report one has to know what the state or event is, and its value. States and events are binary. A state is either on or off and an event either happens or it doesn't. There is no corresponding HL7 data type for this kind of measurement thus the [ASN1ToHL7](CodeSystem-ASN1ToHL7.html) code system has been developed to express these states and events as codes. A Boolean is used to express the corresponding values. Measurement values of this type are mapped to an Observation following the [Phd Bits Enumeration Observation profile](StructureDefinition-PhdBitsEnumerationObservation.html). -Each event or state is reported in a component element. The `Observation.code` will be the ASN1ToHL7 code indicating what the state or event is. The value of the state or event will be a Boolean value. It should be noted that 'state' values must be reported for either state. It is as important to know whether the door is opened or closed. Events are only required to be reported when they happen. +Each event or state is reported in a component element. The `Observation.component.code` will be the ASN1ToHL7 code indicating what the state or event is. The value of the state or event will be a Boolean value. It should be noted that 'state' values must be reported for either state. It is as important to know whether the door is opened or closed. Events are only required to be reported when they happen. Implementers should not make any assumption about the state assignment. For example, to assume that 'something opened' is signified by a `true` can lead to misinterpretation. The monitor specification may have been designed with the idea that everything closed was the desired state and signified it with `true`. The ASN1ToHL7 code system will have the assignment and readers will need to examine it. -In future PHD versions the PHD will be able to indicate that is does not support certain state or event flags in a given measurement report. This situation is expressed by replacing the `Observation.valueCodeableConcept` element with an `Observation.dataAbentReason` element with reason "unsupported". Currently there are no market PHDs that support this feature. +PHD can indicate that is does not support certain state or event flags in a given measurement report. This situation is expressed by replacing the `Observation.component.valueCodeableConcept` element with an `Observation.component.dataAbsentReason` element with reason "unsupported". Currently there are no market PHDs that support this feature. -Event and/or state measurements have no primary `Observation.value[x]` entry and there is no `Observation.dataAbsentReason` unless the *entire* measurement has an error, in which case there will be no state of event entries either. It is possible for each state or event entry to be unsupported and that will be reported with a `Observation.dataAbsentReason` element. Even if every `Observation.component` entry reports 'unsupported' that does not have the same meaning as the entire measurement being in error. +Observations following the [Phd Bits Enumeration Observation profile](StructureDefinition-PhdBitsEnumerationObservation.html) have no primary `Observation.value[x]` entry and there is no `Observation.dataAbsentReason` unless the *entire* measurement has an error, in which case there will be no state or event entries either. It is possible for each state or event entry to be unsupported and that will be reported with a `Observation.dataAbsentReason` element. Even if every `Observation.component` entry reports 'unsupported' that does not have the same meaning as the entire measurement being in error. -In structure the states and/or events measurements are similar to compound or vector measurements. It is also possible that state and/or event measurements have '*additional descriptions*' as discussed in the [Additional Descriptive Data](#additional-descriptive-data) section. To distinguish the measurement component entries from the additional description component entries one only needs to examine the Observation.component.code.coding.system. If it is ASN1ToHL7, it is part of the measurement. +In structure these Observations are similar to compound Observations. It is also possible that '*additional descriptions*' as discussed in the [Additional Descriptive Data](#additional-descriptive-data) section are present. Each `Observation.component` entry will have the following: