From 6ce9ed67ddf845e755a9e5e2e83d7b08a196e100 Mon Sep 17 00:00:00 2001 From: Erik Moll Date: Thu, 17 Jul 2025 15:57:29 +0200 Subject: [PATCH 01/10] slicing in bits observation, various Jira tickets and more Use of Liquid tag for FHIR spec base URL Use of Code style for resource elements in some .md files Removed terminology.md file / page --- .cspell/custom-dictionary-workspace.txt | 1 + FHIR-phd.xml | 2 +- input/PhdImplementationGuide.xml | 5 - ...finition.PhdBitsEnumerationObservation.fsh | 10 +- ...ctureDefinition.PhdCompoundObservation.fsh | 20 +- ...CapabilityStatement-PhdFHIRServer-intro.md | 2 +- ...tureDefinition-PhdBaseObservation-notes.md | 4 +- .../StructureDefinition-PhdDevice-notes.md | 4 +- ...eDefinition-PhdNumericObservation-notes.md | 26 +- input/pagecontent/Glossary.md | 2 + input/pagecontent/MderFLOATsandSFLOATs.md | 48 ++-- input/pagecontent/ObtainObservationCode.md | 2 +- input/pagecontent/ProfileConsumers.md | 242 +++++++++--------- input/pagecontent/terminology.md | 34 --- 14 files changed, 192 insertions(+), 210 deletions(-) delete mode 100644 input/pagecontent/terminology.md diff --git a/.cspell/custom-dictionary-workspace.txt b/.cspell/custom-dictionary-workspace.txt index d366fcc..28dcc04 100644 --- a/.cspell/custom-dictionary-workspace.txt +++ b/.cspell/custom-dictionary-workspace.txt @@ -8,6 +8,7 @@ PCHA pleth plethysmograph RTMMS +SFLOAT SNOMED timestamping UCUM diff --git a/FHIR-phd.xml b/FHIR-phd.xml index 106ac02..a94f985 100644 --- a/FHIR-phd.xml +++ b/FHIR-phd.xml @@ -166,7 +166,7 @@ - + diff --git a/input/PhdImplementationGuide.xml b/input/PhdImplementationGuide.xml index 7ffee43..72d615f 100644 --- a/input/PhdImplementationGuide.xml +++ b/input/PhdImplementationGuide.xml @@ -551,11 +551,6 @@ In this example there are only xml structure definitions, value sets, code syste <generation value="markdown"/> </page> - <page> - <nameUrl value="terminology.html"/> - <title value="Terminology"/> - <generation value="markdown"/> - </page> <page> <nameUrl value="Organizations.html"/> <title value="Organizations"/> diff --git a/input/fsh/StructureDefinition.PhdBitsEnumerationObservation.fsh b/input/fsh/StructureDefinition.PhdBitsEnumerationObservation.fsh index 8a96702..d151a45 100644 --- a/input/fsh/StructureDefinition.PhdBitsEnumerationObservation.fsh +++ b/input/fsh/StructureDefinition.PhdBitsEnumerationObservation.fsh @@ -13,20 +13,20 @@ Description: "Observations from a PHD where the measurement is an ASN1 BITS valu * . ^definition = "The PhdBitsEnumerationObservation reports PHD measurements that contain a bitstring attribute." * ^comment = "This type of measurement is used when the Personal Health Device reports a measurement as an IEEE 11073-10101 BITs value." * value[x] ..0 -* component ^slicing.discriminator[1].type = #value - * ^slicing.discriminator[=].path = "code" - * ^slicing.rules = #open +// * component ^slicing.discriminator[1].type = #value +// * ^slicing.discriminator[=].path = "code" +// * ^slicing.rules = #open * component contains bitsComponent 0..* * component[bitsComponent] ^short = "BITs measurements entry components" * ^definition = "Each ASN1 component entrant contains one of the reported BITs settings. These entries are NOT present if the Measurement-Status attribute field indicates an error." * code from $ASN1MeasurementBits (required) - * coding.system = "http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7" (exactly) + // * coding.system = "http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7" (exactly) * value[x] only boolean * dataAbsentReason 0..1 * ^short = "For the optional reporting of unsupported bits" * ^definition = "Provides a reason why the expected value in the element Observation.component.value[x] is missing. In this profile for this component that happens if the PHD does not support this bit and the uploader wishes to report that situation." * coding ^short = "FHIR code for reporting 'unsupported'" - * code = #unsupported (exactly) + * coding = http://terminology.hl7.org/CodeSystem/data-absent-reason#unsupported * valueBoolean ^short = "The value of the bit" * ^definition = "The value of the bit. If the bit is set the value is `true` and if the bit is cleared the value is `false`." diff --git a/input/fsh/StructureDefinition.PhdCompoundObservation.fsh b/input/fsh/StructureDefinition.PhdCompoundObservation.fsh index 3e47542..f4ef620 100644 --- a/input/fsh/StructureDefinition.PhdCompoundObservation.fsh +++ b/input/fsh/StructureDefinition.PhdCompoundObservation.fsh @@ -58,16 +58,16 @@ Description: "Observations from a PHD where the measurement is a set of numbers * ^definition = "A series of data points which are the sampled values." * valueString ^short = "The value of the string component" * ^definition = "The value of the string component" -* component - * dataAbsentReason ^short = "Populated when the component value is invalid or unavailable for some reason" - * ^definition = "Provides a reason why the expected value in the component is missing. For numeric components this could be not-a-number, negative-infinity or similar." - * coding ^slicing.discriminator[0].type = #value - * ^slicing.discriminator[=].path = "code" - * ^slicing.rules = #open - * coding contains FhirDefault 1..1 - * coding[FhirDefault] - * code from $DataAbsentReason (required) - * code 1.. +// * component +// * dataAbsentReason ^short = "Populated when the component value is invalid or unavailable for some reason" +// * ^definition = "Provides a reason why the expected value in the component is missing. For numeric components this could be not-a-number, negative-infinity or similar." +// * coding ^slicing.discriminator[0].type = #value +// * ^slicing.discriminator[=].path = "code" +// * ^slicing.rules = #open +// * coding contains FhirDefault 1..1 +// * coding[FhirDefault] +// * code from $DataAbsentReason (required) +// * code 1.. * component * extension contains http://hl7.org/fhir/uv/phd/StructureDefinition/Accuracy named Accuracy 0..1 * extension contains http://hl7.org/fhir/uv/phd/StructureDefinition/Confidence95 named Confidence95 0..1 diff --git a/input/intro-notes/CapabilityStatement-PhdFHIRServer-intro.md b/input/intro-notes/CapabilityStatement-PhdFHIRServer-intro.md index 3980aa9..1cf23e9 100644 --- a/input/intro-notes/CapabilityStatement-PhdFHIRServer-intro.md +++ b/input/intro-notes/CapabilityStatement-PhdFHIRServer-intro.md @@ -4,4 +4,4 @@ Such PHGs transcode data from PHDs following the IEEE 11073-10206 data model to This capability statement specifies only those capabilities needed for a FHIR server to receive data from a PHG following this IG. ### Patient Upload -A server may refuse the upload of a Patient resource to protect Personal Health Information (PHI). Administrators of such servers provide the uploader the logical id of the Patient resource by an unspecified means. The client uses the logical id in its Observation resources as needed. The Patient resource may or may not exist on the server but the Observation resource shall not be rejected by the server due to a resource not found error if it uses the provided logical id. In those situations where the Patient resource is uploaded by the client the resource is only required to contain an opaque identifier. In this manner, PHI is still protected as only the service provider has the key linking the identifier to an actual patient. +A server may refuse the upload of a Patient resource to protect health information (PHI). Administrators of such servers provide the uploader the logical id of the Patient resource by an unspecified means. The client uses the logical id in its Observation resources as needed. The Patient resource may or may not exist on the server but the Observation resource shall not be rejected by the server due to a resource not found error if it uses the provided logical id. In those situations where the Patient resource is uploaded by the client the resource is only required to contain an opaque identifier. In this manner, PHI is still protected as only the service provider has the key linking the identifier to an actual patient. diff --git a/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md b/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md index a77fc0e..8aca5cf 100644 --- a/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md +++ b/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md @@ -101,7 +101,7 @@ This mapping is quite often semantically incorrect. In FHIR the session observat ### Category The category element identifies the observation as being generated by a PHD. This can be used in searches and distinguishes such observations from observations collected using clinical equipment or collected in a clinical context. PHGs shall include a category element with a fixed coding as specified by the profile. -Note that for vital signs observations there also should be a category element as defined by the [Vital Signs profile](https://hl7.org/fhir/R4/observation-vitalsigns.html). +Note that for vital signs observations there also should be a category element as defined by the [Vital Signs profile]({{ site.data.fhir.path }}observation-vitalsigns.html). ### Supplemental Information - Components Component elements are used whenever the observation contains additional information attributes that further describe the observation. PHD observations can include Supplemental-Information that can be mapped to one or more FHIR Observation components. @@ -143,7 +143,7 @@ The table below lists the error conditions and the FHIR data elements to which t | Thresholding disabled | interpretation = PoCDStatus#alarm-inhibited | Applies to numeric data. Add a note to the Observation resource that its boundaries are not checked. Should be used in combination with the SimpleAlerting Extension. | DAR: [Data Absent Reason CodeSystem](http://terminology.hl7.org/CodeSystem/data-absent-reason) -HL7Status: [Observation Status CodeSystem](http://hl7.org/fhir/observation-status) +HL7Status: [Observation Status CodeSystem]({{ site.data.fhir.path }}observation-status) PoCDStatus: [CodeSystem: Measurement Status Codes CodeSystem](https://hl7.org/fhir/uv/pocd/2021Sep/ValueSet-observation-interpretation.html) ActReason: [CodeSystem: Act Reason CodeSystem](http://terminology.hl7.org/CodeSystem/v3-ActReason) diff --git a/input/intro-notes/StructureDefinition-PhdDevice-notes.md b/input/intro-notes/StructureDefinition-PhdDevice-notes.md index 7a24a6f..f4c845a 100644 --- a/input/intro-notes/StructureDefinition-PhdDevice-notes.md +++ b/input/intro-notes/StructureDefinition-PhdDevice-notes.md @@ -5,7 +5,7 @@ All IEEE 11073-10206 PHDs are required to have a system identifier. This usually In order to discriminate between an identifier that is a system id and that which is a transport address the identifier.type element is used. A dedicated CodeSystem [Device Identifier Codes](CodeSystem-ContinuaDeviceIdentifiers.html) has the codes one can use to populate the identifier.type.coding.code element. -When in the future other system identifiers such as ETSI-ICCID (International Circuit Card Identifier) or other identifiers are used, this coding scheme will need to be extended. +When in the future other system identifiers such as ETSI-ICCID (International Circuit Card Identifier) are used, this coding scheme will need to be extended. The transport addresses are as follows: @@ -20,6 +20,8 @@ padding: 6px;}</style> |Bluetooth|EUI-48|BTMAC|http://hl7.org/fhir/sid/eui-48/bluetooth|00-E5-DE-AD-77-C3| |ZigBee|EUI-64|ZIGBEE|http://hl7.org/fhir/sid/eui-64/zigbee|36-ED-9A-EE-DE-AD-77-C3| +The URIs used for the system can be found in the [External Identifier Systems](https://terminology.hl7.org/identifiers.html). + An example of a system identifier is: {% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON EXCEPT:identifier %} diff --git a/input/intro-notes/StructureDefinition-PhdNumericObservation-notes.md b/input/intro-notes/StructureDefinition-PhdNumericObservation-notes.md index 45d9950..d7832c9 100644 --- a/input/intro-notes/StructureDefinition-PhdNumericObservation-notes.md +++ b/input/intro-notes/StructureDefinition-PhdNumericObservation-notes.md @@ -1,4 +1,4 @@ -This profile is used to map ACOM Numeric Observations. The measured value is reported as a floating number with an optional accuracy. In GHS the value is encoded as an IEEE 11073 FLOAT that indicates both precision and the number of significant digits. The Observation.valueQuantity.value element is required to honor the reported precision. See [Mder FLOATs and SFLOATs](MderFLOATsandSFLOATs.html) for instructions on handling S/FLOATs and their encoding to the valueQuantity . +This profile is used to map ACOM Numeric Observations. The measured value is reported as a floating number with an optional accuracy. In GHS the value is encoded as an IEEE 11073 FLOAT that indicates both precision and the number of significant digits. The `Observation.valueQuantity.value` element is required to honor the reported precision. See [Mder FLOATs and SFLOATs](MderFLOATsandSFLOATs.html) for instructions on handling S/FLOATs and their encoding to the valueQuantity . ### Mapping the unit code to FHIR The MDC unit code as provided by the PHD needs to be mapped to UCUM. In most cases this mapping is straight forward, but there can be some examples which are tricky. The MDC_DIM_TICK for the RR interval is just the number of ticks. However, the tick unit is given by the Clock.time-resolution attribute which is the number of ticks per second. So if clock resolution is 0.5 ms and the RR measurement is 3000, that means the RR interval is 1.5 seconds. One could also express the measurement in Hertz. When the units are converted in this manner, the value must be converted appropriately. @@ -22,7 +22,7 @@ The accuracy is reported in the same unit as the measurement itself. An example The simple alerting extension supports monitoring a numerical value (quantities in FHIR) and provisioning of an alarm if the value is outside a defined threshold or limiting range. The extension includes the range, the operational state of the monitoring and text strings desribing these. See [Simple Alerting](StructureDefinition-SimpleAlerting.html). The PHD pulse oximeter and the continuous glucose monitor specialization support this. The extension defines a current limits range for the quantity, an operational state and optional strings for the operational state and the semantics of the quantity being outside the range. -This mechanism is used in combination with the Observation.interpretation value being set to "in-alarm" when the quantity is outside the limits. +This mechanism is used in combination with the `Observation.interpretation` value being set to "in-alarm" when the quantity is outside the limits. The presence of the extension in an Observation with a numeric quantity informs the consumer of the use of the alerting mechanism. @@ -30,7 +30,7 @@ An example of an observation with an alert can be found [here](Observation-numer ##### Measurement Confidence 95 The Measurement-Confidence-95 gives a lower and upper bound with which the manufacturer is 95% confident that the actual reported measurement is within that bounds. The Measurement Confidence 95 applies only to measurement values that are quantities. It is supported by the IEEE 11073-20601 specification, but not by the IEEE 11073-10206 ACOM specification. -It shall be reported if the PHD provides it. When static it can be reported as an extension in a Device Metric, otherwise it is reported as an extension of an Observation. See [Confidence95 extension](StructureDefinition-Confidence95.html). The range is encoded in an Extension.valueRange element. The ranges have the same units as the primary measurement. +It shall be reported if the PHD provides it. When static it can be reported as an extension in a Device Metric, otherwise it is reported as an extension of an Observation. See [Confidence95 extension](StructureDefinition-Confidence95.html). The range is encoded in an `Extension.valueRange` element. The ranges have the same units as the primary measurement. The IEEE 11073-20601 Measurement-Confidence-95 component is currently used only in the Continuous Glucose specialization. An example of a Measurement Confidence 95 entry is shown below: {% fragment Observation/glucose-observation JSON EXCEPT:extension[2] %} @@ -43,11 +43,11 @@ A basic simple numeric observation with a timestamp and a supplemental types att An example of a NaN (not a number) measurement is shown in [NaN Example](Observation-numeric-observation-not-a-number.html). Note that the value element is absent and replaced by a dataAbsentReason element. ### Consumer of the PHD Numeric Observation Profile -The consumer of this profile does not need to concern itself with the mapping complexities or the PHD-related entry for the Observation.identifier which is used by the uploader to prevent data duplication. There are some extensions introduced by this profile but the resource is consumable by any reader that understands the Observation resource. The following table summarizes the elements used describing the measurement: +The consumer of this profile does not need to concern itself with the mapping complexities or the PHD-related entry for the `Observation.identifier` which is used by the uploader to prevent data duplication. There are some extensions introduced by this profile but the resource is consumable by any reader that understands the Observation resource. The following table summarizes the elements used describing the measurement: | **Measurement Item** | **Element** | **Additional Information** | |-------------------------------|------------------------------------------|-----------------------------------------------------------------------------------------------------------------| -| Measurement type | `Observation.code.coding.code` | There shall be one coding element using the MDC coding system.<br>If a vital sign, there will be an additional coding element using one of the LOINC 'magic' codes. | +| Measurement type | `Observation.code.coding.code` | There shall be one coding element using the MDC coding system.<br>If a vital sign, there will be an additional coding element using one of the LOINC vital-signs codes. | | Measurement value | `Observation.valueQuantity.value` | The value has the precision of the original. measurement. | | Measurement units | `Observation.valueQuantity.code` | FHIR uses UCUM coding. system. | | Error | `Observation.dataAbsentReason` | Contains error code. If present, no `Observation.valueQuantity` is present. | @@ -58,3 +58,19 @@ The consumer of this profile does not need to concern itself with the mapping co | Additional descriptions | `Observation.extension.*` | When present it contains additional information about the measurement. | | Patient | `Observation.subject` | Points to the Patient resource. | | Sensor device | `Observation.device` | Points to the Device resource. | + + +### Try out of Jekyll/Liquid variables: + +| Variable Name | Liquid | Value | +|---------------|-------|--| +| path | page.path | {{ page.path }} | +| FHIR path | site.data.fhir.path | {{ site.data.fhir.path }} | +| FHIR version | site.data.fhir.version | {{ site.data.fhir.version }} | +| canonical | site.data.fhir.canonical | {{ site.data.fhir.canonical }} | +| ig | site.data.fhir.ig | {{ site.data.fhir.ig }} | +| igId | site.data.fhir.igId | {{ site.data.fhir.igId }} | +| ig.version | site.data.fhir.ig.version | {{ site.data.fhir.ig.version }} | +| ig.name | site.data.fhir.ig.name | {{ site.data.fhir.ig.name }} | +| ig.title | site.data.fhir.ig.title | {{ site.data.fhir.ig.title }} | +| ig.tx-server | site.data.fhir.ig.tx-server | {{ site.data.fhir.ig.tx-server }} | \ No newline at end of file diff --git a/input/pagecontent/Glossary.md b/input/pagecontent/Glossary.md index 5975033..27f2519 100644 --- a/input/pagecontent/Glossary.md +++ b/input/pagecontent/Glossary.md @@ -13,11 +13,13 @@ This glossary lists abbreviations and acronyms used throughout this Implementati | HL7 | Health Level Seven International | | IHE | Integrating the Healthcare Enterprise | | IG | Implementation Guide | +| LOINC | Logical Observation Identifiers Names and Codes | | MDC | Medical Device Communication (nomenclature codes, IEEE 11073-10101) | | MRN | Medical Record Number | | PCHA | Personal Connected Health Alliance | | PHD | Personal Health Device | | PHG | Personal Health Gateway | +| PHI | Protected Health Information | | PII | Personally Identifiable Information | | RTMMS | Rosetta Terminology Mapping Management System | | SIG | Special Interest Group (as in Bluetooth SIG) | diff --git a/input/pagecontent/MderFLOATsandSFLOATs.md b/input/pagecontent/MderFLOATsandSFLOATs.md index c8eb810..01182cf 100644 --- a/input/pagecontent/MderFLOATsandSFLOATs.md +++ b/input/pagecontent/MderFLOATsandSFLOATs.md @@ -1,15 +1,32 @@ -Mder FLOATs and SFLOATs are the IEEE 11073-20601 means of encoding floating point numbers. The primary reason for this encoding is to indicate the precision of the measurement. The SFLOAT is 16-bits and the FLOAT is 32-bits. In the SFLOAT, the most significant 4 bits is the exponent and the remaining 12 bits the mantissa. In the FLOAT, the most significant byte is the exponent and the remaining 24 bits the mantissa. Both the exponent and mantissa are signed. +Mder FLOATs and SFLOATs are the IEEE 11073 means of encoding floating point numbers. The primary reason for this encoding is to indicate the precision of the measurement. The FLOAT is 32-bits and the SFLOAT is 16-bits. In the FLOAT, the most significant byte is the exponent and the remaining 24 bits the mantissa. Both the exponent and mantissa are signed. In the SFLOAT, the most significant 4 bits is the exponent and the remaining 12 bits the mantissa. The exponent gives the precision. It indicates where the decimal point goes in the mantissa. A negative exponent of -*N* moves the decimal point to the left *N* places and a positive exponent of +*N* moves the decimal point to the right *N* places. Thus, it is possible in this encoding to distinguish between the value 2, 2.0, 2.00, etc. Numerically, they all have the same value, but 2.00 indicates that the value is two but taken with a sensor that has a precision to the hundredths. -The table below gives some examples of SFLOAT values and how they shall be encoded into the FHIR valueQuantity.value: +The Bluetooth GHS specifications only use FLOATs to encode quantitative values; the IEEE 11073-20601 specification uses both FLOATs and SFLOATs. + +#### FLOAT Encoding +The table below gives some examples of FLOAT values and how they shall be encoded into the FHIR valueQuantity.value: <style>table, th, td { border: 1px solid black; border-collapse:collapse; padding: 6px;}</style> +|FLOAT Hex|FLOAT decimal|exponent|mantissa|FHIR encoding| +|---|---|---|---|---| +|0x00000002|2|0|2|2| +|0xFF000014|4278190100|-1|20|2.0| +|0xFE0000C8|4261413064|-2|200|2.00| +|0x01000002|4098|1|2|20| +|0x02000002|33554434|2|2|200| +|0x000000C8|200|0|200|200| +|0x000004D2|1234|0|1234|1234| +|0x00FFFB2E|16775982|0|-1234|-1234| + + +#### SFLOAT Encoding +In the SFLOAT case the above values would be encoded as follows: |SFLOAT Hex|SFLOAT decimal|exponent|mantissa|FHIR encoding| |---|---|---|---|---| @@ -22,26 +39,13 @@ padding: 6px;}</style> |0x04D2|1234|0|1234|1234| |0x0B2E|2862|0|-1234|-1234| -In the FLOAT case the above values would be encoded as follows: - -|FLOAT Hex|FLOAT decimal|exponent|mantissa|FHIR encoding| -|---|---|---|---|---| -|0x00000002|2|0|2|2| -|0xFF000014|4278190100|-1|20|2.0| -|0xFE0000C8|4261413064|-2|200|2.00| -|0x01000002|4098|1|2|20| -|0x02000002|33554434|2|2|200| -|0x000000C8|200|0|200|200| -|0x000004D2|1234|0|1234|1234| -|0x00FFFB2E|16775982|0|-1234|-1234| - #### Special Values -The Mder encoding also has a set of 5 reserved special values which represent some type of error condition. They are as follows: +The Mder encoding also has a set of 5 reserved special values which represent some type of error condition. The table shows these values and how they shall be encoded in FHIR. The FHIR `Observation.dataAbsentReason` is used to indicate the meaning of the special value. -|FLOAT Case|SFLOAT case|meaning|FHIR encoding| +|FLOAT Case|SFLOAT case|meaning|FHIR mapping| |---|-|-|-| -|0x007FFFFF|0x7FF|Not a Number (NaN)|.dataAbsentReason set to 'not-a-number'| -|0x007FFFFE|0x7FE|Positive Infinity (+inf)|.dataAbsentReason set to 'positive-infinity'| -|0x00800002|0x802|Negative Infinity (-inf)|.dataAbsentReason set to 'negative-infinity'| -|0x00800000|0x800|Not at this resolution|.dataAbsentReason set to 'error'| -|0x00800001|0x801|Reserved for future use|.dataAbsentReason set to 'error'| +|0x007FFFFF|0x7FF|Not a Number (NaN)|`not-a-number`| +|0x007FFFFE|0x7FE|Positive Infinity (+Inf)|`positive-infinity`| +|0x00800002|0x802|Negative Infinity (-Inf)|`negative-infinity`| +|0x00800000|0x800|Not at this resolution (NRes)|`error`| +|0x00800001|0x801|Reserved for future use (RFU)|`error`| diff --git a/input/pagecontent/ObtainObservationCode.md b/input/pagecontent/ObtainObservationCode.md index c615b03..7924ffa 100644 --- a/input/pagecontent/ObtainObservationCode.md +++ b/input/pagecontent/ObtainObservationCode.md @@ -3,7 +3,7 @@ The Observation.code element is populated as follows: * if the application wishes to transcode this MDC code into other coding systems the application is free to do so but * the MDC code shall be present in a coding element - * if the code matches one of the [FHIR observation-vitalsigns codes]( https://www.hl7.org/fhir/observation-vitalsigns.html)), the observation-vitalsigns code shall be present in a coding element + * if the code matches one of the [FHIR observation-vitalsigns codes](https://hl7.org/fhir/R4/observation-vitalsigns.html), the observation-vitalsigns code shall be present in a coding element * any other coding translations desired may be placed in an additional coding element. * for the MDC code the mapping is as follows: * Observation.code.coding.code = *value* diff --git a/input/pagecontent/ProfileConsumers.md b/input/pagecontent/ProfileConsumers.md index 365fd38..4fade20 100644 --- a/input/pagecontent/ProfileConsumers.md +++ b/input/pagecontent/ProfileConsumers.md @@ -31,24 +31,24 @@ Every PHD generated measurement Observation resource contains the following info |---|---|---| |type|`code`|This element tells you what the measurement is. There should be a coding element using the MDC coding system.<br>If a vital sign, there will be an additional coding element using one of the [LOINC vital sign codes](https://hl7.org/fhir/R4/valueset-observation-vitalsignresult.html).| ||`category`|The category element is present with at least the value `"phd"`. For vital signs, there will also be another element with value `"vital-signs"` as required by the vital signs profile. -|measurement-status|Observation.status,<br> Observation.data-absent-reason|This element tells what the status of the measurements is and has usually the value `final`. In error cases the data-absent-reason element is filled with an appropriate value. -|timestamp|Observation.effectiveDateTime,<br/>Observation.effectivePeriod|This element tells when the measurement occurred, and is a point in time or a period with a start- and end-time.| -|PHG reference|Observation.extension.valueReference|This element points to the PHG Device that generated the FHIR resources. The gateway extension is identified by Observation.extension.url=["http://hl7.org/fhir/StructureDefinition/observation-gatewayDevice"](http://hl7.org/fhir/StructureDefinition/observation-gatewayDevice.html)| -|patient reference|Observation.subject|Points to the Patient to whom this measurement refers| -|PHD reference|Observation.device|Points to the PHD Device that took the measurement| +|measurement-status|`Observation.status`,<br> `Observation.dataAbsentReason`|This element tells what the status of the measurements is and has usually the value `final`. In error cases the data-absent-reason element is filled with an appropriate value. +|timestamp|`Observation.effectiveDateTime`,<br/>`Observation.effectivePeriod`|This element tells when the measurement occurred, and is a point in time or a period with a start- and end-time.| +|PHG reference|`Observation.extension.valueReference`|This element points to the PHG Device that generated the FHIR Observation. The gateway extension is identified by `Observation.extension.url="http://hl7.org/fhir/StructureDefinition/observation-gatewayDevice"`| +|patient reference|`Observation.subject`|Points to the Patient to whom this measurement refers| +|PHD reference|`Observation.device`|Points to the PHD Device that took the measurement| In this section each of the fields summarized above is discussed. -##### The Measurement Type: Observation.code.coding.code +##### The Measurement Type: `Observation.code.coding.code` The measurement type tells what the measurement is. In HL7 such information is typically done through codes and it is no different here. However, one must understand the coding system in order to interpret what the code means. Consumers of the PHD profiles must understand the MDC code system to interpret the measurement. One can find more information about the MDC code system [here](https://terminology.hl7.org/MDC.html). MDC codes are available from the [Rosetta Terminology Mapping Management Service (RTMMS)](https://rtmms.nist.gov/). It provides descriptions and, if applicable, the units associated with the measurement in both MDC and UCUM. Equivalent LOINC codes are also provided. The Rosetta system is updated on a regular basis with new codes and corrections. For those consumer applications that would like to have the codes as LOINC and the uploader did not provide them, a mapping table between MDC and LOINC is also included in LOINC since v2.54 [available here](https://loinc.org/news/loinc-version-2-54-and-relma-version-6-12-available/). The FHIR MDC to LOINC concept map is available [here](https://fhir.loinc.org/ConceptMap/?url=http://loinc.org/cm/loinc-to-ieee-device-codes). One may freely download and use this material as needed in an implementation, but it does require a (free) login account. A mapping from MDC to SNOMED CT for some of the more common codes is available in the somewhat outdated Continua Design Guidelines [H.813 HIS Interface](https://www.itu.int/rec/T-REC-H.813-201911-I) document. The guidelines are freely available for download, however [licensing requirements](https://www.snomed.org/licensing) for the use of the SNOMED CT code system apply. -FHIR (R4) requires that a LOINC code is present if the measurement is one of the vital signs given [here](https://hl7.org/fhir/R4/observation-vitalsigns.html). In that case, the Observation.code shall have at least a second coding element containing the LOINC "magic value". *The consumer must be aware that the MDC-to-LOINC mapping may be many to one*. For example, both the pulse rate obtained from a Blood Pressure Cuff (149546) and the pulse rate obtained from a Pulse Oximeter (149530) may be mapped to the LOINC code (8867-4). A PHG may map these MDC codes also to more specific LOINC codes. +FHIR (R4) requires that a LOINC code is present if the measurement is one of the vital signs given [here](https://hl7.org/fhir/R4/observation-vitalsigns.html). In that case, the `Observation.code` shall have at least a second coding element containing a LOINC code. *The consumer must be aware that the MDC-to-LOINC mapping may be many to one*. For example, both the pulse rate obtained from a Blood Pressure Cuff (149546) and the pulse rate obtained from a Pulse Oximeter (149530) may be mapped to the LOINC code (8867-4). A PHG may map these MDC codes also to more specific LOINC codes. -In addition to the LOINC code, FHIR requires an Observation.category.coding.code element with value "vital-signs" when the measurement is a vital sign. +In addition to the LOINC code, FHIR requires an `Observation.code` element with value "vital-signs" when the measurement is a vital sign. #### The Timestamp: Observation.effective[x] All measurements contain a timestamp which is either an instant in time, a dateTime data type, or a period of time, a Period data type. The period has both a start and end. Results of a workout session are a common type of measurement with a period. The 'instant' data type is not used as it is permissible for PHDs to report time at resolutions greater than a day in which case there is no time zone. An activity monitor reporting only daily summaries could be an example of a PHD using such a resolution. @@ -65,27 +65,27 @@ The reference to the Device resource containing the PHG properties is encoded in {% fragment Observation/temperature-observation JSON EXCEPT:extension[0] %} -#### The Patient reference: Observation.subject: -The reference to the Patient resource containing information about the patient upon whom the measurement was taken is placed in the Observation.subject element. -In many cases the patient is also the person that is taking the measurement. In other cases a general physician may be using a PHD in his clinic. When known to the gateway a reference to the performer may be present in an Observation.performer element. +#### The Patient reference: `Observation.subject`: +The reference to the Patient resource containing information about the patient upon whom the measurement was taken is placed in the `Observation.subject` element. +In many cases the patient is also the person that is taking the measurement. In other cases a general physician may be using a PHD in his clinic. When known to the gateway a reference to the performer may be present in an `Observation.performer` element. #### The PHD reference -The reference to the PHD device is placed in the Observation.device element. +The reference to the PHD device is placed in the `Observation.device` element. There is a dedicated profile for the PHD device that is used to capture the system information, clock and power information that the PHG receives from the PHD. -#### Other Observation Element Fields +#### Other Observation Elements In addition to the elements that are always present, the following set of elements may be present. |IEEE 11073-10206 attribute|FHIR data element|Description| |----|---|---| -|Observation class|Observation.meta.profile|When present this element contains canonical URL of structure definitions of the profiles this Observation conforms to.| -|clock.current-time |Observation.extension.valueReference|Points to Observation following the Coincident Timestamp Observation profile that records the PHD's current time. This is used for time quality auditing purposes. May be present only when the PHD provides a timestamp. | -|related observations|Observation.derivedFrom Observation.hasMember|Points to a PHD Observation that is related to this Observation. An example would be an activity session that has a miles run measurement member. Only present if the observation references another observation.| -|additional descriptions|Observation.component or Observation.extension|Sometimes a measurement is sent containing additional information such as the technique used to obtain the measurement. These elements are placed in a component or an extension.| -||Observation.identifier|This element is used to prevent data duplication during uploads.| - -##### The Profile: Observation.meta.profile -An Observation may contain a meta.profile element that can help to identify the type of the Observation. For example, if Observation.meta.profile entry contains ["http://hl7.org/fhir/uv/phd/StructureDefinition/PhdNumericObservation"](StructureDefinition-PhdNumericObservation.html) the measurement is a scalar. +|Observation class|`Observation.profile`|When present this element contains canonical URL of structure definitions of the profiles this Observation conforms to.| +|clock.current-time |`Observation.extension.valueReference`|Points to Observation following the Coincident Timestamp Observation profile that records the PHD's current time. This is used for time quality auditing purposes. May be present only when the PHD provides a timestamp. | +|related observations|`Observation.derivedFrom` `Observation.hasMember`|Points to a PHD Observation that is related to this Observation. An example would be an activity session that has a miles run measurement member. Only present if the observation references another observation.| +|additional descriptions|`Observation.component` or `Observation.extension`|Sometimes a measurement is sent containing additional information such as the technique used to obtain the measurement. These elements are placed in a component or an extension.| +||`Observation.identifier`|This element is used to prevent data duplication during uploads.| + +##### The Profile: `Observation.meta.profile` +An Observation may contain a `meta.profile` element that can help to identify the type of the Observation. For example, if `Observation.profile` entry contains ["http://hl7.org/fhir/uv/phd/StructureDefinition/PhdNumericObservation"](StructureDefinition-PhdNumericObservation.html) the measurement is a scalar. Note that there is no requirement that the profile element be present. If it is not present, the consumer can determine the type of measurement value by looking at the Observation.value[x] element. ##### The Coincident Timestamp extension @@ -99,7 +99,7 @@ An example of the Coincident Timestamp extension is shown below: Additional information about the Coincident Timestamp can be found [here](CoincidentTimeStamp.html). #### References to Other Observations -There are situations where a given Observation is an important part of another Observation such as a glucose meal context measurement giving additional information about a glucose concentration measurement. In that case the context measurement will have an Observation.derivedFrom.reference element that points to the Observation resource containing the glucose measurement. Another common case where an Observation references another Observation is in an activity monitor. Results of an exercise session such as miles run, calories burned, average and maximum heart rates, etc. are reported as Observations where each Observation points to the master session Observation with a Observation.memberOf.reference which has the activity type and duration (period). +There are situations where a given Observation is an important part of another Observation such as a glucose meal context measurement giving additional information about a glucose concentration measurement. In that case the context measurement will have an `Observation.reference` element that points to the Observation resource containing the glucose measurement. Another common case where an Observation references another Observation is in an activity monitor. Results of an exercise session such as miles run, calories burned, average and maximum heart rates, etc. are reported as Observations where each Observation points to the master session Observation with a `Observation.reference` which has the activity type and duration (period). An example of a reference to another Observation is shown below: @@ -108,19 +108,19 @@ An example of a reference to another Observation is shown below: #### Additional Descriptive Data In this section we further define Observation details that a PHD may provide but are uncommon. The reader may wish to skip to to the description of the measurement values sections [here](#numerics) and return to this section when relevant. -PHDs can send measurements that have additional descriptive information. An example would be a pulse oximeter indicating the modality used when taking the measurement. Some of the additional information reported can only occur if the measurement value is a of a specific value type such as a quantity. This additional information is reported in an Observation.component element. The type of additional information is given by the Observation.component.code element. The value of such additional information is given by an Observation.component or an Observation.extension element. PHDs support the following types of additional information: +PHDs can send measurements that have additional descriptive information. An example would be a pulse oximeter indicating the modality used when taking the measurement. Some of the additional information reported can only occur if the measurement value is a of a specific value type such as a quantity. This additional information is reported in an `Observation.component` element. The type of additional information is given by the `Observation.code` element. The value of such additional information is given by an `Observation.component` or an `Observation.extension` element. PHDs support the following types of additional information: |Type of additional information|When it can occur|FHIR data element|Description| -|- -|supplemental type|Can occur with all measurement values|valueCodeableConcept| provides a further description of the measurement type. Can be multiple supplemental type component entries.| -|Accuracy|Only with Quantities|extension.valueQuantity| Gives the accuracy of the measurement value in the units of the measurement value| -|Measurement Confidence 95|Only with Quantities|extension.valueRange| Gives a range that the manufacturer is 95% confident that the actual reported measurement is within that bounds| -|Simple Alerting|Only with Quantities|complex extension| Gives the parameters for alerting and thresholding on a quantity.| +|----|---|---|---| +|supplemental type|Can occur with all measurement values|`valueCodeableConcept`| provides a further description of the measurement type. Can be multiple supplemental type component entries.| +|Accuracy|Only with Quantities|`extension.valueQuantity`| Gives the accuracy of the measurement value in the units of the measurement value| +|Measurement Confidence 95|Only with Quantities|`extension.valueRange`| Gives a range that the manufacturer is 95% confident that the actual reported measurement is within that bounds| +|Simple Alerting|Only with Quantities|`complex extension`| Gives the parameters for alerting and thresholding on a quantity.| More details on the extensions that can be used with quantities can be found in the [PhdNumericObservation profile](StructureDefinition-PhdNumericObservation.html). ##### Supplemental Types -Supplemental type information is indicated by the Observation.component.code.coding.code element having the value 68193. The value type of a supplemental type entry is always a CodeableConcept and is therefore given by Observation.component.valueCodeableConcept.coding.code. There may be more than one Observation.component entry containing supplemental type information. An example of a supplemental types component entry is as follows: +Supplemental type information is indicated by the `Observation.code` element having the value 68193. The value type of a supplemental type entry is always a CodeableConcept and is therefore given by Observation.component.valueCodeableConcept.coding.code. There may be more than one `Observation.component` entry containing supplemental type information. An example of a supplemental types component entry is as follows: {% fragment Observation/numeric-spotnumeric JSON EXCEPT:component[0] %} @@ -128,19 +128,21 @@ A 'spot modality' means that the pulse oximeter sensed over a period long enough <blockquote class="stu-note"> <strong>Should we move Supplemental Type information to an extension?</strong> - In the PHD IG v1.0 an attempt was made to avoid extensions as much as possible. In this version we are using extensions for less often used elements of IEEE 11073-10206 ACOM and in places were the ACOM model and the FHIR model for an observation are too different to have a 1-1 mapping between data elements of these models. - The question is if this applies to Supplemental Type information as well. Should IEEE 11073-10206 Supplemental Information be modeled as a FHIR Observation.component or as an extension in FHIR? - Input is welcome. +In the PHD IG v1.0 an attempt was made to avoid extensions as much as possible. In this version we are using extensions for less-often used elements of the IEEE 11073 PHD ACOM model and in places were the PHD model and the FHIR model for observation are too different to have a 1-1 mapping between data elements of these models. The question is if this applies to Supplemental Type information as well. +- Is it appropriate to map IEEE supplemental information to `observation.component` as a generic and pragmatic solution? +- Moving forward, should IEEE 11073-10206/20601 Supplemental Information be modeled as a FHIR `Observation.component` or as an extension in FHIR? + +Input is welcome! </blockquote> ### Measurement Status -In normal situations PHD reported Observation resources have a Observation.status element set to "final". However, every real device is going to experience challenges at some time. These challenges can interfere with the measurement and therefore need to be reported. One could argue that measurements with errors should not be delivered, but in a scenario where the PHG might be headless and one is happy that the patient can even take the measurement, it may be important to know that the measurement attempt was made. Therefore this IG supports a PHG to report any measurement it receives from a PHD including error states and let downstream consumers address it. +In normal situations PHD reported Observation resources have a `Observation.status` element set to "final". However, every real device is going to experience challenges at some time. These challenges can interfere with the measurement and therefore need to be reported. One could argue that measurements with errors should not be delivered, but in a scenario where the PHG might be headless and one is happy that the patient can even take the measurement, it may be important to know that the measurement attempt was made. Therefore this IG supports a PHG to report any measurement it receives from a PHD including error states and let downstream consumers address it. There are other non-error special conditions that may also be reported, such as the measurement is test or demo data. -Depending upon what the special condition is, it is reported in either the dataAbsentReason, interpretation, or meta.security element. All of these entries are CodeableConcepts. When the condition is reported in the dataAbsentReason, there will be no measurement value entry in accord with the FHIR specification, even if the PHD reports a measurement value. Note that there may be multiple interpretation entries but only one dataAbsentReason element. +Depending upon what the special condition is, it is reported in either the dataAbsentReason, interpretation, or `meta.security` element. All of these entries are CodeableConcepts. When the condition is reported in the dataAbsentReason, there will be no measurement value entry in accord with the FHIR specification, even if the PHD reports a measurement value. Note that there may be multiple interpretation entries but only one dataAbsentReason element. The exact mapping of IEEE 11073-10206 Observation status conditions to FHIR is covered in the [PhdBaseObservation profile](StructureDefinition-PhdBaseObservation.html). @@ -151,26 +153,26 @@ To prevent data duplication during uploads, and enable use of conditional create <a id="numerics"></a> ### Measurement Values that are numeric or scalar -Scalar numeric measurements are the most common type of measurement reported by PHDs. Temperature, weight, height, miles run, pulse rate, etc. are examples. Scalar numeric measurements are reported in Observation resources following the [Phd Numeric Observation Profile](StructureDefinition-PhdNumericObservation.html). The scalar values are reported in the Observation.valueQuantity element. If the PHD reports a special value; Not a number, Positive infinity, Negative infinity, and two other possible values unknown to FHIR, an Observation.dataAbsentReason element replaces the valueQuantity and there is no value[x] element. +Scalar numeric measurements are the most common type of measurement reported by PHDs. Temperature, weight, height, miles run, pulse rate, etc. are examples. Scalar numeric measurements are reported in Observation resources following the [Phd Numeric Observation Profile](StructureDefinition-PhdNumericObservation.html). The scalar values are reported in the `Observation.valueQuantity` element. If the PHD reports a special FLOAT value; Not a number, Positive infinity, Negative infinity or Not at this resolution, an `Observation.dataAbsentReason` element replaces the valueQuantity and there is no value[x] element. -When there is no special value the Observation.valueQuantity is populated with the scalar value, the units, and the system. The units and system are UCUM unless the PHG does not know the UCUM translation for the MDC unit code. The latter can happen if a new specialization, written after the PHG was implemented, introduces a new MDC unit code not previously used in PHDs. The scalar value is reported with the precision indicated by the PHD. Thus 2 and 2.00 represent the same value but measured to a different precision. +When there is no special value the `Observation.valueQuantity` is populated with the scalar value, the units, and the system. The units and system are UCUM unless the PHG does not know the UCUM translation for the MDC unit code. The latter can happen if a new specialization, written after the PHG was implemented, introduces a new MDC unit code not previously used in PHDs. The scalar value is reported with the precision indicated by the PHD. Thus 2 and 2.00 represent the same value but measured to a different precision. |FHIR element|Description| |---|---| -|Observation.valueQuantity.value|Measurement value: It will have the precision reported by the PHD, thus the numerical value 2 could be reported as 2, 2.0, or 2.00 depending upon the sensor precision| -|Observation.valueQuantity.code|units in UCUM| -|Observation.valueQuantity.system="http://unitsofmeasure.org"|code system is UCUM| +|`Observation.valueQuantity.value`|Measurement value: It will have the precision reported by the PHD, thus the numerical value 2 could be reported as 2, 2.0, or 2.00 depending upon the sensor precision| +|`Observation.valueQuantity.code`|units in UCUM| +|`Observation.valueQuantity.system="http://unitsofmeasure.org"`|code system is UCUM| -If a special value is reported an Observation.dataAbsentReason replaces the valueQuantity. The dataAbsentReason is a CodeableConcept and will have the following possible codes from the data absent reason coding system "http://terminology.hl7.org/CodeSystem/data-absent-reason": +If a special value is reported an `Observation.dataAbsentReason` replaces the valueQuantity. The dataAbsentReason is a CodeableConcept and will have the following possible codes from the data absent reason coding system "http://terminology.hl7.org/CodeSystem/data-absent-reason": - - Observation.dataAbsentReason.coding.code="not-a-number" - - Observation.dataAbsentReason.coding.code="positive-infinity" - - Observation.dataAbsentReason.coding.code="negative-infinity" - - Observation.dataAbsentReason.coding.code="error" + - `Observation.dataAbsentReason.coding.code="not-a-number"` + - `Observation.dataAbsentReason.coding.code="positive-infinity"` + - `Observation.dataAbsentReason.coding.code="negative-infinity"` + - `Observation.dataAbsentReason.coding.code="error"` -The Observation.dataAbsentReason.coding.system in the above cases is always +The `Observation.system` in the above cases is always - - Observation.dataAbsentReason.coding.system="http://terminology.hl7.org/CodeSystem/data-absent-reason" + - `Observation.dataAbsentReason.coding.system="http://terminology.hl7.org/CodeSystem/data-absent-reason"` IEEE 11073-20601 defines two other special values that are not translated to FHIR which are encoded as "error". To date, there has been no market PHD which reports the other two special values. @@ -180,18 +182,18 @@ An example of the valueQuantity in the Phd Numeric Observation Profile for a the ### Measurement Values that are Compounds IEEE 11073-10206 (ACOM) supports compound observations where the components can have a numeric, a string, a code or a sample array value. This type of observation is mapped to the [Phd Compound Observation](StructureDefinition-PhdCompoundObservation.html) profile. -There is no primary Observation.value[x] entry and there is no Observation.dataAbsentReason unless the *entire* measurement had an error, in which case there will be no compound entries either. It is possible for each compound entry to have its own error and that will be reported in an Observation.component.dataAbsentReason element. All Observation.component entries could have dataAbsentReason entry but that does NOT mean the entire measurement has an Observation.dataAbsentReason entry. It is also possible that a component will have its own interpretation element of the same type as shown in the Measurement Status section. Currently there are no market PHDs that generate an Observation.component.interpretation element. -There is no primary Observation.value[x] entry and there is no Observation.dataAbsentReason unless the *entire* measurement had an error, in which case there will be no compound entries either. It is possible for each compound entry to have its own error and that will be reported in an Observation.component.dataAbsentReason element. All Observation.component entries could have dataAbsentReason entry but that does NOT mean the entire measurement has an Observation.dataAbsentReason entry. +There is no primary Observation.value[x] entry and there is no `Observation.dataAbsentReason` unless the *entire* measurement had an error, in which case there will be no compound entries either. It is possible for each compound entry to have its own error and that will be reported in an `Observation.dataAbsentReason` element. All `Observation.component` entries could have dataAbsentReason entry but that does NOT mean the entire measurement has an `Observation.dataAbsentReason` entry. It is also possible that a component will have its own interpretation element of the same type as shown in the Measurement Status section. Currently there are no market PHDs that generate an `Observation.interpretation` element. +There is no primary Observation.value[x] entry and there is no `Observation.dataAbsentReason` unless the *entire* measurement had an error, in which case there will be no compound entries either. It is possible for each compound entry to have its own error and that will be reported in an `Observation.dataAbsentReason` element. All `Observation.component` entries could have dataAbsentReason entry but that does NOT mean the entire measurement has an `Observation.dataAbsentReason` entry. -Compound Observations will have a code indicating what the 'entire' measurement is, for example, non-invasive blood pressure or acceleration. Each Observation.component element will have its own code describing each individual compound or vector entry, for example, the systolic, diastolic, and mean pressures for the blood pressure or x-, y-, and z-projections of an acceleration. +Compound Observations will have a code indicating what the 'entire' measurement is, for example, non-invasive blood pressure or acceleration. Each `Observation.component` element will have its own code describing each individual compound or vector entry, for example, the systolic, diastolic, and mean pressures for the blood pressure or x-, y-, and z-projections of an acceleration. -Each Observation.component will have the following: +Each `Observation.component` will have the following: |FHIR element|Description| |---|---| -|Observation.component.code.coding.code|MDC code telling what the entry is| -|Observation.component.code.coding.system="urn:iso:std:iso:11073:10101"|MDC code system identifier| -|Observation.component.value[x]|contains the value of the component being a Quantity, CodeableConcept, string or SampledData| +|`Observation.component.code.coding.code`|MDC code telling what the entry is| +|`Observation.component.code.coding.system="urn:iso:std:iso:11073:10101"`|MDC code system identifier| +|`Observation.component.value[x]`|contains the value of the component being a Quantity, CodeableConcept, string or SampledData| #### Measurement Values that are Numeric Compounds @@ -199,23 +201,23 @@ IEEE 11073-20601 does only support compound measurements with numeric components |FHIR element|Description| |---|---| -|Observation.component.valueQuantity.value|the scalar value of the given entry with the precision indicated by the PHD| -|Observation.component.valueQuantity.code|the units (as UCUM)| -|Observation.component.valueQuantity.system="http://unitsofmeasure.org"|UCUM code system identifier| +|`Observation.component.valueQuantity.value`|the scalar value of the given entry with the precision indicated by the PHD| +|`Observation.component.valueQuantity.code`|the units (as UCUM)| +|`Observation.component.valueQuantity.system="http://unitsofmeasure.org"`|UCUM code system identifier| -Note that the Observation.component.code element is subject to the same FHIR LOINC magic value requirement as the Observation.code element if the component is one of the vital signs [here](https://hl7.org/fhir/R4/observation-vitalsigns.html). The Systolic and diastolic pressures are in that list, but the MEAN component is not. +Note that the `Observation.code` element is subject to the same FHIR LOINC code requirement as the `Observation.code` element if the component is one of the vital signs [here](https://hl7.org/fhir/R4/observation-vitalsigns.html). The Systolic and Diastolic pressures are in that list, but the MEAN component is not. An example of a Blood Pressure measurement would be as follows: -The Observation.code and Observation.category (since the measurement is a vital sign) entries describing the 'entire' measurement: +The `Observation.code` and `Observation.category` (since the measurement is a vital sign) entries describing the 'entire' measurement: {% fragment Observation/compound-numeric-blood-pressure-no-mean JSON EXCEPT:code|category %} -and the individual Observation.component entries describing each compound entry where the MEAN entry was unable to be determined and reported a NaN (Not a Number): +and the individual `Observation.component` entries describing each compound entry where the MEAN entry was unable to be determined and reported a NaN (Not a Number): {% fragment Observation/compound-numeric-blood-pressure-no-mean JSON EXCEPT:component %} -The Phd Compound Numeric Profile can contain additional entries as noted in the [Additional Descriptive Data](#additional-descriptive-data) section above. However, the codes of all Observation.component entries that are part of a compound measurement will always have an MDC entry (not ASN1ToHL7) and the MDC entry will ***never*** have a partition value (the upper 16 bits) equal to 1. +The Phd Compound Numeric Profile can contain additional entries as noted in the [Additional Descriptive Data](#additional-descriptive-data) section above. However, the codes of all `Observation.component` entries that are part of a compound measurement will always have an MDC entry (not ASN1ToHL7) and the MDC entry will ***never*** have a partition value (the upper 16 bits) equal to 1. #### Remark on compound observations The decision to report a compound observation versus independent observations is made by the designers of the IEEE PHD device specialization standards. The IEEE PHD and FHIR policies to choose between these options are similar. This IG maps an ACOM compound observation to a FHIR Observation resource with multiple components. @@ -223,7 +225,7 @@ The decision to report a compound observation versus independent observations is ### Measurement Values that are Codes Sometimes the PHD measurement value is a code. The code comes from the MDC code system. Measurements that are codes follow the [Phd Coded Enumeration Observation profile](StructureDefinition-PhdCodedEnumerationObservation.html). -The measurement value is reported in an Observation.valueCodeableConcept element. Coded measurements are usually 'context' measurements that provide extra information about another measurement. They will often have an Observation.derivedFrom reference pointing to the Observation resource they support. There are no coded enumeration measurements that are vital signs. +The measurement value is reported in an `Observation.valueCodeableConcept` element. Coded measurements are usually 'context' measurements that provide extra information about another measurement. They will often have an `Observation.derivedFrom` reference pointing to the Observation resource they support. There are no coded enumeration measurements that are vital signs. An example of a coded measurement is a meal context in a glucose monitor: @@ -236,23 +238,23 @@ PHDs support a measurement value type that indicate a set of states or events, f Measurement values that fall into this category 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.component.code will be the ASN1ToHL7 code indicating what the state or event is. The value of the state or event will be in an Observation.component.valueCodeableConcept entry using the V2 binary code system. 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.code` will be the ASN1ToHL7 code indicating what the state or event is. The value of the state or event will be in an `Observation.valueCodeableConcept` entry using the V2 binary code system. 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 "Y" 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 "Y". 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.component.valueCodeableConcept element with an Observation.component.dataAbentReason element with reason "unsupported". Currently there are no market PHDs that support this feature. +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. -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.component.dataAbsentReason element. Even if every Observation.component entry reports 'unsupported' that does not have the same meaning as the entire measurement being in error. +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. 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. -Each Observation.component entry will have the following: +Each `Observation.component` entry will have the following: |FHIR element|Description| |---|---| -|Observation.component.code.coding.code|ASN1ToHL7 code telling what the entry is| -|Observation.component.code.coding.system="http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7"|ASN1ToHL7 code system identifier| -|Observation.component.valueBoolean +|`Observation.component.code.coding.code`|ASN1ToHL7 code telling what the entry is| +|`Observation.component.code.coding.system="http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7"`|ASN1ToHL7 code system identifier| +|`Observation.component.valueBoolean`|contains the value of the state or event being true or false| The 'independent living' example mentioned above does not currently exist in any specialization but it is illustrative of the concept. However, a pulse oximeter device sensor status measurement containing several different events does exist. An example of such a measurement can be found [here](Observation-bits-observation.html) @@ -262,18 +264,18 @@ All of the entries are events in this example so the values are always "Y" indic Periodic measurements are typically waveforms like ECG traces and are a sequence of scalars. Measurement values that fall into this category are mapped to an Observation following the [Phd Rtsa Observation profile](StructureDefinition-PhdRtsaObservation.html). 'Rtsa' means real time sample array. -Periodic measurements are reported in Observation.valueSampledData data elements as follows: +Periodic measurements are reported in `Observation.valueSampledData` data elements as follows: |FHIR element|Description| |---|---| -|Observation.valueSampledData.data[i]|Contains the scaled samples separated by spaces| -|Observation.valueSampledData.origin.code<br/>Observation.valueSampledData.origin.system|Contains the units (as UCUM) <br/>"http://unitsofmeasure.org"| -|Observation.valueSampledData.origin.value|Contains the intercept value in the rescaling equation| -|Observation.valueSampledData.scaleFactor|Contains the scale factor in the rescaling equation| -|Observation.valueSampledData.period|gives the time interval between samples in milliseconds| -|Observation.valueSampledData.dimensions|Always 1 in PHD (multi-dimensional arrays are not supported)| -|Observation.valueSampledData.upperLimit |Upper value that the original sequence can obtain| -|Observation.valueSampledData.lowerLimit |Lower value that the original sequence can obtain| +|`Observation.valueSampledData.data[i]`|Contains the scaled samples separated by spaces| +|`Observation.valueSampledData.origin.code`<br/>`Observation.valueSampledData.origin.system`|Contains the units (as UCUM code) <br/>"http://unitsofmeasure.org"| +|`Observation.valueSampledData.origin.value`|Contains the intercept value in the rescaling equation| +|`Observation.valueSampledData.scaleFactor`|Contains the scale factor in the rescaling equation| +|`Observation.valueSampledData.period`|gives the time interval between samples in milliseconds| +|`Observation.valueSampledData.dimensions`|Always 1 in PHD (multi-dimensional arrays are not supported)| +|`Observation.valueSampledData.upperLimit`|Upper value that the original sequence can obtain| +|`Observation.valueSampledData.lowerLimit`|Lower value that the original sequence can obtain| To obtain the original values of the measured sequence one uses the following equation: @@ -284,22 +286,17 @@ or the familiar equation of a line y(i) = mx(i) + b -The Observation.referenceRange element is for convenience and is not necessary for decoding the data. It was designed for plotting as it gives the upper and lower bounds of the trace at any time (it does not mean that either value is obtained in the transmitted sequence). One can create a graph with such limits without examining the sequence. +The `Observation.referenceRange` element is for convenience and is not necessary for decoding the data. It was designed for plotting as it gives the upper and lower bounds of the trace at any time (it does not mean that either value is obtained in the transmitted sequence). One can create a graph with such limits without examining the sequence. -It is possible that the periodic measurement is a vital sign, for example, a heart rate. If it is a vital sign, the same FHIR-required LOINC magic value rules apply as they do for scalar and vector measurements. +It is possible that the periodic measurement is a vital sign, for example, a heart rate. If it is a vital sign, the same FHIR-required LOINC code requirements apply as they do for scalar and vector measurements. ### String measurements -PHDs can send a measurement value that is a human readable string. An example of such a measurement might be the name of a customized exercise program on a piece of gym equipment. - -String measurement values are mapped to an Observation following the [PhdStringObservation profile](StructureDefinition-PhdStringObservation.html). - -The measurement is reported in an Observation.valueString element which has the value of the human readable string. +PHDs can send a measurement value that is a human readable string. An example of such a measurement might be the name of a customized exercise program on a piece of gym equipment. String measurement values are mapped to an Observation following the [PhdStringObservation profile](StructureDefinition-PhdStringObservation.html). The string is reported in an `Observation.valueString` element. An example of this measurement is as follows: {% fragment Observation/string-observation-1 JSON EXCEPT:valueString %} -String measurements are rare in PHDs. ### The PHD Coincident Timestamp Observation Resource The coincident timestamp is a comparison of the PHD's and PHG's timelines. PHDs have limited resources and are often battery driven and therefore depend upon the user or the PHG to set its time. Though it is possible for PHDs to support an external time synchronization there are currently no market PHDs that do such. The timelines of PHDs can therefore be dubious. PHGs are required to support external time synchronization and if possible, to obtain the local offset to UTC. @@ -313,10 +310,10 @@ The coincident timestamp also indicates whether there is a time fault. In the ca The following core information is available from the coincident timestamp observation: |FHIR element|Description| -|- -|Observation.code.coding.code|MDC code that indicates what type of time clock is used by PHD. It is one of:<br/>absolute time (local time with no offset to UTC)<br/>base offset time (local time with offset to UTC)<br/>relative time (a tick count)<br/>high resolution relative time (a tick count with high resolution)| -|Observation.effectiveDateTime|the PHG's current time - absent if the PHD is better synchronized than the PHG| -|Observation.valueDateTime<br/>Observation.valueQuantity<br/>Observation.dateAbsentReason.coding.code="unknown"|the PHD's current time if base offset or absolute time<br/>the PHD's current time if a relative time<br/>PHD has a time fault| +|----|---| +|`Observation.code.coding.code`|MDC code that indicates what type of time clock is used by PHD. It is one of:<br/>absolute time (local time with no offset to UTC)<br/>base offset time (local time with offset to UTC)<br/>relative time (a tick count)<br/>high resolution relative time (a tick count with high resolution)| +|`Observation.effectiveDateTime`|the PHG's current time - absent if the PHD is better synchronized than the PHG| +|`Observation.valueDateTime`<br/>`Observation.valueQuantity`<br/>`Observation.dateAbsentReason.coding.code="unknown"`|the PHD's current time if base offset or absolute time<br/>the PHD's current time if a relative time<br/>PHD has a time fault| If the Observation containing the measurement has no reference to a coincident timestamp, it means the PHD provided no measurement timestamp and the PHG used the time of reception as the current timestamp. @@ -329,39 +326,38 @@ The PHD Device resource follows the [Phd Device Profile](StructureDefinition-Phd The PHD Device resource contains the following information about the PHD in the following elements: - - Device.identifier + - `Device.identifier` - **IEEE EUI-64 System identifier** - IEEE EUI-48 Bluetooth Address if the PHD uses Bluetooth transports - EUI-64 ZigBee address if the PHD uses ZigBee transports - - USB Pid and Vid values if the PHD uses USB transports - - Device.manufacturer + - `Device.manufacturer` - **Manufacturer name** - - Device.modelNumber + - `Device.modelNumber` - **Model number** - - Device.serialNumber - - *serial number* - - Device.partNumber + - `Device.serialNumber` + - serial number + - `Device.partNumber` - part number - - Device.type + - `Device.type` - **PHD (Simple MDS)** - - Device.version - - *firmware version* + - `Device.version` + - firmware version - hardware version - software version - protocol version - Continua version - - Device.specialization + - `Device.specialization` - **Specialization (Blood pressure, thermometer, etc.)** - **Specialization version** - - Device.property - - *Time clock capabilities* - - **Time clock synchronization method** + - `Device.property` + - Time clock capabilities + - Time clock synchronization method - Time synchronization accuracy - Time clock resolution - Regulation status - Certified transports and specializations -The bold items are required to be reported by all PHDs and the italicized items are exposed by most PHDs. The transport addresses are only exposed in the transport protocol and are, of course, only applicable to PHDs using that transport. It is encouraged by the PHG implementer to add the wireless transport address identifiers since these numbers are often available on the device whereas the system id is not. However, obtaining these addresses may not always be possible on certain platforms. +The **bold** items are required to be reported by all PHDs and the italicized items are exposed by most PHDs. The transport addresses are only exposed in the transport protocol and are, of course, only applicable to PHDs using that transport. It is encouraged by the PHG implementer to add the wireless transport address identifiers since these numbers are often available on the device whereas the system id is not. However, obtaining these addresses may not always be possible on certain platforms. #### UDI The UDI (Unique Device Identifier) is supported by the PHD Device profile as an optional element. It is supported by the IEEE 11073-10206 standard and the Bluetooth GHS specifications. When provided by the PHD the actual UDI string will be in human readable form and comes with metadata identifying the issuer and the regulatory authority @@ -375,10 +371,10 @@ An example is shown below: #### Simple String Entries There are several Device elements that are just basic strings. Their meanings are straight forward. In the Phd Device profile they are the following: - - Device.manufacturer - - Device.modelNumber - - Device.serialNumber - - Device.partNumber + - `Device.manufacturer` + - `Device.modelNumber` + - `Device.serialNumber` + - `Device.partNumber` #### Device Type This field states that the device is a PHD. There is no code in the list of device types provided by FHIR [here](https://hl7.org/fhir/R4/valueset-device-type.html) that indicates a personal health device. Instead we use the MDC code that indicates a simple MDS (Medical Device System) object. This entry will be identical for all PHDs following this IG. It appears as follows: @@ -387,7 +383,7 @@ This field states that the device is a PHD. There is no code in the list of devi #### Versions -The Device.versions entry is an array of CodeableConcepts. A single version is unable to represent a PHD as they have a version for the sensor hardware, the internal protocol they may be using, the communication software, sensor firmware, and even the Continua or ACOM version their communication software supports. Not all devices will expose all this information but most PHDs expose their firmware and software versions. +The `Device.versions` entry is an array of CodeableConcepts. A single version is unable to represent a PHD as they have a version for the sensor hardware, the internal protocol they may be using, the communication software, sensor firmware, and even the Continua or ACOM version their communication software supports. Not all devices will expose all this information but most PHDs expose their firmware and software versions. The [MDC Device Version Type codes ValueSet](ValueSet-MDCDeviceVersionTypes.html) has a code to identify each one of these version types. The version itself it just a simple alpha-numeric string. The versions can be helpful identifying different PHD behaviors. @@ -396,7 +392,7 @@ Below is an example of the different versions exposed by a PHD: #### Specializations -The Device.specialization entry is probably the entry most consumers will want to inspect. This entry states what kind of measurements the PHD takes. It is this entry that tells the consumer if the PHD is a blood pressure cuff, heart rate monitor, pulse oximeter. PHDs can support multiple specializations. This element shall always be populated. +The `Device.specialization` entry is probably the entry most consumers will want to inspect. This entry states what kind of measurements the PHD takes. It is this entry that tells the consumer if the PHD is a blood pressure cuff, heart rate monitor, pulse oximeter. PHDs can support multiple specializations. This element shall always be populated. In IEEE 11073-10206 ACOM specializations are, in addition to a general description of what the PHD is, standards. The specialization standards are a refinement of the generic standard, and have versions. @@ -411,7 +407,7 @@ The property element contains time clock information and certification informati There are two types of properties, one that is described by a list of codes, and one that is described by a list of quantities. The list often contains only one entry. Though not obvious from the FHIR specification, a property cannot contain *both* a quantity and coded element. -The Device.property.type is a CodeableConcept which tells what the property is. There are [MDC](https://terminology.hl7.org/MDC.html) or [ASN1ToHL7](CodeSystem-ASN1ToHL7.html) codes for each property type a PHD can expose. They are as follows: +The `Device.type` is a CodeableConcept which tells what the property is. There are [MDC](https://terminology.hl7.org/MDC.html) or [ASN1ToHL7](CodeSystem-ASN1ToHL7.html) codes for each property type a PHD can expose. They are as follows: |description|Code|Reference identifier| |--|--|--| @@ -458,7 +454,7 @@ An example of time synchronization property entry is shown below: ##### Time Capabilities The time capabilities defines the types of real time clocks supported, whether the time can be set, whether external time synchronization is possible, etc. Each capability is treated as an event, so most PHGs will only report the capability if the PHD indicates it has the capability. The value is a single valueCode which will be either "Y" if the PHD has the capability or "N" if not. Most PHGs will not report the "N" case as that would significantly increase the size of the resource on the wire. There may be several such time capability property entries. -The time capabilities property is indicated by the Device.property.type.coding.code having one of the ASN1ToHL7 codes of "68219.x" which is NOT a decimal number! The value is a valueCode with codes "Y" or "N". +The time capabilities property is indicated by the `Device.code` having one of the ASN1ToHL7 codes of "68219.x" which is NOT a decimal number! The value is a valueCode with codes "Y" or "N". The example below gives the time capabilities of a market pulse oximeter: @@ -469,7 +465,7 @@ The time clock resolutions is given by one of four MDC codes for each of the pos The resolution value is a valueQuantity and it gives the time interval between clock 'pulses', regardless of the type of time clock, in units of microseconds. -The property is indicated by the Device.property.type.coding.code having one of four MDC codes "68222, 68223, 68224, and 68226". The value is a valueQuantity. +The property is indicated by the `Device.code` having one of four MDC codes "68222, 68223, 68224, and 68226". The value is a valueQuantity. An example of a time resolution property for an absolute time clock with a time resolution of of one second is shown below: {% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON EXCEPT:property[0] %} @@ -493,11 +489,11 @@ An example of a time resolution property for an absolute time clock with a time } #### Time Tick Resolution for R-R Intervals -The Time Tick resolution is not used for measurement timestamps but for measuring R-R intervals (time between electrocardiogram R-wave peaks) in ECG and Heart Rate specializations. The number of ticks is reported in the valueQuantity.value element in Observations, not the effective[x] which is the time the measurement is taken. These special clocks typically have a resolution of 1024 Hz or better. When R-R intervals are reported, they are reported in units of these ticks, so one must know what the frequency of the clock is. The reason for this special clock is that R-R intervals have been traditionally timed using dedicated crystal oscillators. +The Time Tick resolution is not used for measurement timestamps but for measuring R-R intervals (time between electrocardiogram R-wave peaks) in ECG and Heart Rate specializations. The number of ticks is reported in the `valueQuantity.value` element in Observations, not the effective[x] which is the time the measurement is taken. These special clocks typically have a resolution of 1024 Hz or better. When R-R intervals are reported, they are reported in units of these ticks, so one must know what the frequency of the clock is. The reason for this special clock is that R-R intervals have been traditionally timed using dedicated crystal oscillators. The time tick is given as a property and its units are Hertz. However, the R-R interval is given in the number of these ticks and many PHGs will not make the conversion as there is no UCUM code for the MDC dimension code of Ticks and therefore the units reported will be the MDC unit of ticks. Thus the reader will have to obtain the R-R interval using the R-R reported tick value and the tick frequency given in the Device property element. -The property is indicated by the Device.property.type.coding.code having the MDC code "68229". The value is a valueQuantity. +The property is indicated by the `Device.code` having the MDC code "68229". The value is a valueQuantity. An example of the Tick resolution property entry is given below. @@ -523,7 +519,7 @@ An example of the Tick resolution property entry is given below. #### Time Synchronization Accuracy The time synchronization accuracy is the accumulated difference between the PHD's internal clock and external reference source since last synchronization. It is reported in units of microseconds. To date no PHD is externally time synchronized so no PHD reports this attribute value. -The property is indicated by the Device.property.type.coding.code having the MDC code "68221". The value is a valueQuantity. +The property is indicated by the `Device.code` having the MDC code "68221". The value is a valueQuantity. An example of the time synchronization accuracy property entry is given below. @@ -549,7 +545,7 @@ An example of the time synchronization accuracy property entry is given below. #### Regulation Status The Regulation status is a set of states where only one state is defined. Regulation Status is used to indicate which regulation body the PHD is regulated by. At the moment, the single defined state is assumed to be FDA. All market devices that currently report a regulated state are FDA regulated. -The property is indicated by the Device.property.type.coding.code having the ASN1ToHL7 code "532354.x" where the only currently defined entry is x=0. The value is a valueCode which can have a value "Y" or "N". The twist here is that the state has been defined in the negative. ***Thus a code value of "N" means regulated.*** Note that since this is a state, the PHG is required to report both the "Y" and "N" values *if* the PHD reports a regulation status. +The property is indicated by the `Device.code` having the ASN1ToHL7 code "532354.x" where the only currently defined entry is x=0. The value is a valueCode which can have a value "Y" or "N". The twist here is that the state has been defined in the negative. ***Thus a code value of "N" means regulated.*** Note that since this is a state, the PHG is required to report both the "Y" and "N" values *if* the PHD reports a regulation status. An example of an entry for an FDA regulated device is shown below: @@ -558,7 +554,7 @@ An example of an entry for an FDA regulated device is shown below: #### Continua Certified PHD Interfaces This property contains a code that indicates a specialization and transport the PHD has been (self-)certified for. Note there is a difference between 'support' and 'certified' support. The Device specialization entries indicate what the PHD supports. Certified means the PHD has been (independently) placed through a set of extensive tests for the specialization and the transport over which the specialization operates. In the past, the Continua organization certified PHDs for compliance to its guidelines that referenced this IG. -The property is indicated by the Device.property.type.coding.code having the MDC code "532353". The value is a code from the [ValueSet for PHD Interfaces](ValueSet-ContinuaPHDInterfaces.html) code system. +The property is indicated by the `Device.code` having the MDC code "532353". The value is a code from the [ValueSet for PHD Interfaces](ValueSet-ContinuaPHDInterfaces.html) code system. An example of a property entry where a PHD is certified for the pulse oximeter specialization over both Bluetooth Low Energy, USB, and Continua version 1.0 where there was no transport indicated, is given below: @@ -579,7 +575,7 @@ This field states that the device is a PHG. This IG uses the MDC code MDC_MOC_VM #### Certified Health and Fitness Interfaces This property is a list of codes that indicate which Health and Fitness interfaces the PHG has been *certified* for. There is no certification body active for this IG, so this entry can be populated with interfaces the PHG supports. -The property is indicated by the Device.property.type.coding.code having the MDC code "532355". The value is a list of valueCodes where the codes come from the [ContinuaHFS](CodeSystem-ContinuaHFS.html) code system. The code system is simple and limited to only eight values at the current time. +The property is indicated by the `Device.code` having the MDC code "532355". The value is a list of valueCodes where the codes come from the [ContinuaHFS](CodeSystem-ContinuaHFS.html) code system. The code system is simple and limited to only eight values at the current time. An example of a PHG resource is given [here](Device-phg-example.html). @@ -590,16 +586,16 @@ The Patient resource is following the Phd Patient Profile as defined [here](Stru There is only one additional required entry in the Phd Patient Profile; the Patient.identifier. -The required Patient.identifier entry contains an identifier.type using the [Table 0203 identifierType](http://terminology.hl7.org/CodeSystem/v2-0203) code system from HL7 v2. The code entry is generally "MR" for medical record number, but other likely entries are "LR" for local registry or "U" for unspecified identifier. The "U" is also used when handling a "John or Jane Doe" unknown patient. +The required `Patient.identifier` entry contains an `identifier.type` using the [Table 0203 identifierType](http://terminology.hl7.org/CodeSystem/v2-0203) code system from HL7 v2. The code entry is generally "MR" for medical record number, but other likely entries are "LR" for local registry or "U" for unspecified identifier. The "U" is also used when handling a "John or Jane Doe" unknown patient. -The identifier.value and identifier.system entries are used to quantify the entries of the given identifier.type. For example, the identifier.system might be the institution's XDS.b assigning authority and the identifier.value the patient record number (also known as the patient identifier). See [IHE Cross-Enterprise Document Sharing](https://profiles.ihe.net/ITI/TF/Volume1/ch-10.html). +The `identifier.value` and `identifier.system` entries are used to quantify the entries of the given identifier.type. For example, the `identifier.system` might be the institution's XDS.b assigning authority and the `identifier.value` the patient record number (also known as the patient identifier). See [IHE Cross-Enterprise Document Sharing](https://profiles.ihe.net/ITI/TF/Volume1/ch-10.html). Note that a medical record number is considered PHI in some jurisdictions and use cases. Even when the medical record number is not in itself PHI, the fact that the PHG's communication will convey both the MRN and health data could put the whole communication into the realm of PHI. -An example of a Patient.identifier following the XDS.b notation is given below: +An example of a `Patient.identifier` following the XDS.b notation is given below: {% fragment Patient/patientExample-1 JSON EXCEPT:identifier %} -An example of an unknown patient using the identifier.type "U" is given [here](Patient-patientExample-2.html) +An example of an unknown patient using the `identifier.type` "U" is given [here](Patient-patientExample-2.html) diff --git a/input/pagecontent/terminology.md b/input/pagecontent/terminology.md deleted file mode 100644 index a7e5632..0000000 --- a/input/pagecontent/terminology.md +++ /dev/null @@ -1,34 +0,0 @@ -## Terminology - -The ISO/IEEE 11073-10101 Nomenclature standard (MDC) provides a comprehensive terminology for device models according to the ISO/IEEE 11073-10201 and IEEE 11073-10206 Domain information models (DIM). -It is the required code system for profiles in this implementation guide. Other additional coding systems expressing the same concepts may also be used. -Reference identifiers, terminology codes, and descriptions are available at the <a href="https://rtmms.nist.gov/rtmms/index.htm">Rosetta Terminology Mapping Management System</a> (RTMMS). - -<p>The PHD profiles define rules for terminology usage:</p> -<ul> -<li> - <code>Device.specializations</code> shall have a coding from the IEEE 11073-10101 MDC Infra partition describing the device specializations and sub-profile standards the PHD conforms to. As the specialization elements are of type CodeableConcept there can be additional codings from other code systems. -</li> -</ul> -<p>The <a href="http://hl7.org/fhir/observation-vitalsigns.html">Vital Signs Profile</a>, which is part of FHIR core specification, applies for some commonly used measurement observations (e. g., heart rate, blood pressure, respiratory rate, oxygen saturation, body temperature). The main impact this core requirement imposes on the PHD profiles is that for measurements that are considered vital signs, the LOINC code for that vital sign must be present. -</p><p> -Consequently for vital signs measurements the <code>Observation.code</code> and, for compound metrics, the <code>Observation.component.code</code> elements must contain a matching <a href="http://hl7.org/fhir/loinc.html">LOINC</a> code in addition to the required IEEE 11073-10101 MDC code. -</p><p> -The Vital Signs Profile also specifies that the Quantity data type in <code>Observation.value[x]</code> and <code>Observation.component.value[x]</code> contains the units of measure which shall be <a href="http://hl7.org/fhir/ucum.html">UCUM</a>. The PHD profiles extends this requirement for all measurements that are of type Quantity, with the exception of rare cases where no UCUM code is defined. -</p> - -### Code Systems - -<table class="table-striped" style="width:100%"> -<col style="width:40%"/> -<col style="width:60%"/> -{% include table-codesystems.xhtml %} -</table> - -### Value Sets - -<table class="table-striped" style="width:100%"> -<col style="width:40%"/> -<col style="width:60%"/> -{% include table-valuesets.xhtml %} -</table> From 17c52ee4f6b4001f05a84f0e0b4aa2d7dbace142 Mon Sep 17 00:00:00 2001 From: Erik Moll <erik.moll@philips.com> Date: Fri, 18 Jul 2025 21:11:21 +0200 Subject: [PATCH 02/10] various fixes slicing of component.dataAbsentReason to get rid of warning use of Liquid tag for FHIR base path further use of `code` style in.md pagees --- input-cache/schemas/R5/fhir-single.xsd | 6 ++-- input/fsh/CodeSystem.ASN1ToHL7.fsh | 2 +- ...finition.PhdBitsEnumerationObservation.fsh | 8 +++-- ...tureDefinition-PhdBaseObservation-notes.md | 16 +++++----- .../StructureDefinition-PhdDevice-notes.md | 2 +- input/pagecontent/CodeableConcepts.md | 4 +-- input/pagecontent/CoincidentTimeStamp.md | 32 +++++++++---------- input/pagecontent/ObtainObservationCode.md | 2 +- input/pagecontent/ProfileConsumers.md | 14 ++++---- 9 files changed, 45 insertions(+), 41 deletions(-) diff --git a/input-cache/schemas/R5/fhir-single.xsd b/input-cache/schemas/R5/fhir-single.xsd index c49b758..b1284fa 100644 --- a/input-cache/schemas/R5/fhir-single.xsd +++ b/input-cache/schemas/R5/fhir-single.xsd @@ -47,7 +47,7 @@ POSSIBILITY OF SUCH DAMAGE. - Generated on Fri, Jul 11, 2025 16:31+0000 for FHIR v6.0.0-ballot2 + Generated on Fri, Jul 18, 2025 15:40+0000 for FHIR v6.0.0-ballot2 --> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://hl7.org/fhir" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns:xml="http://www.w3.org/XML/1998/namespace" targetNamespace="http://hl7.org/fhir" elementFormDefault="qualified" version="6.0.0-ballot2"> <!-- Note: When using this schema with some tools, it may also be necessary to declare xmlns:xml="http://www.w3.org/XML/1998/namespace", however this causes performance issues with other tools and thus is not in the base schemas. --> @@ -31002,7 +31002,7 @@ The actual author of the section when it is not the author of the composition. I </xs:element> <xs:element name="device" minOccurs="1" maxOccurs="1" type="Reference"> <xs:annotation> - <xs:documentation xml:lang="en">Reference to the devices associated with the patient or group.</xs:documentation> + <xs:documentation xml:lang="en">Reference to the device that is being associated.</xs:documentation> </xs:annotation> </xs:element> <xs:element name="relationship" minOccurs="0" maxOccurs="unbounded" type="CodeableConcept"> @@ -64134,7 +64134,7 @@ Deceased patients may also be marked as inactive for the same reasons, but may b <xs:documentation xml:lang="en">A free-text description of what is to be performed.</xs:documentation> </xs:annotation> </xs:element> - <xs:element name="focus" minOccurs="0" maxOccurs="1" type="Reference"> + <xs:element name="focus" minOccurs="0" maxOccurs="unbounded" type="Reference"> <xs:annotation> <xs:documentation xml:lang="en">The request being fulfilled or the resource being manipulated (changed, suspended, etc.) by this task.</xs:documentation> </xs:annotation> diff --git a/input/fsh/CodeSystem.ASN1ToHL7.fsh b/input/fsh/CodeSystem.ASN1ToHL7.fsh index 3708daa..c824860 100644 --- a/input/fsh/CodeSystem.ASN1ToHL7.fsh +++ b/input/fsh/CodeSystem.ASN1ToHL7.fsh @@ -33,7 +33,7 @@ Description: "CodeSystem for mapping IEEE 11073-10206 bitstrings to FHIR Codeabl * ^property[=].uri = "http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7#MDCCode" * ^property[=].description = "The decimal code for the MDC code of the bits observation" * ^property[=].type = #Coding -// values for properties are defined here for FHIR R4, although that is not the best way to do it +// values for properties are defined here, although that is probably not the best way to do it * #source "Source" "The source of the bit" * #eventOrState "Event or State" "Whether the bit represents an event or a state" * #device "Attribute" "The bit represents a device attribute" diff --git a/input/fsh/StructureDefinition.PhdBitsEnumerationObservation.fsh b/input/fsh/StructureDefinition.PhdBitsEnumerationObservation.fsh index d151a45..f5625e8 100644 --- a/input/fsh/StructureDefinition.PhdBitsEnumerationObservation.fsh +++ b/input/fsh/StructureDefinition.PhdBitsEnumerationObservation.fsh @@ -23,10 +23,14 @@ Description: "Observations from a PHD where the measurement is an ASN1 BITS valu // * coding.system = "http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7" (exactly) * value[x] only boolean * dataAbsentReason 0..1 + * dataAbsentReason.coding ^slicing.discriminator.type = #value + * dataAbsentReason.coding ^slicing.discriminator.path = "$this" + * dataAbsentReason.coding ^slicing.rules = #open + * dataAbsentReason.coding contains unsupported 0..1 + * dataAbsentReason.coding[unsupported] * ^short = "For the optional reporting of unsupported bits" * ^definition = "Provides a reason why the expected value in the element Observation.component.value[x] is missing. In this profile for this component that happens if the PHD does not support this bit and the uploader wishes to report that situation." - * coding ^short = "FHIR code for reporting 'unsupported'" - * coding = http://terminology.hl7.org/CodeSystem/data-absent-reason#unsupported + * dataAbsentReason.coding[unsupported] = http://terminology.hl7.org/CodeSystem/data-absent-reason#unsupported * valueBoolean ^short = "The value of the bit" * ^definition = "The value of the bit. If the bit is set the value is `true` and if the bit is cleared the value is `false`." diff --git a/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md b/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md index 8aca5cf..f6c23b5 100644 --- a/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md +++ b/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md @@ -55,14 +55,14 @@ The PHG can work with the assumption that the PHD and the PHG are always in the For IEEE 11073-10206 timestamps the following table can be used: -| Time type | Current | Synced | Offset | Recommended Mapping | -| ------------ | ------- | ------ | ------ | ----------------------------------------------------------------------- | -| UTC | Yes | Yes | Yes | Keep as is with optional correction to PHG timeline, keep offset as is | -| UTC | Yes | Yes | No | Keep as is , with optional correction and optionally include PHG offset | -| UTC | Yes | No | Yes | Map to PHG timeline, including PHG offset | -| UTC | Yes | No | No | Map to PHG UTC timeline, optionally include PHG offset | +| Time type | Current | Synced | Offset | Recommended Mapping | Coincident Timestamp Observation | +| ------------ | ------- | ------ | ------ | ----------------------------------------------------------------------- | --------------------------------- | +| UTC | Yes | Yes | Yes | Keep as is with optional correction to PHG timeline, keep offset as is | Yes | +| UTC | Yes | Yes | No | Keep as is, with optional correction and include PHG offset | Yes | +| UTC | Yes | No | Yes | Map to PHG timeline, including PHG offset | Yes | +| UTC | Yes | No | No | Map to PHG UTC timeline, include PHG offset | Yes | | UTC | No | Yes | Yes | Keep as is | -| UTC | No | Yes | No | Keep as is, optionally include PHG offset | +| UTC | No | Yes | No | Keep as is, include PHG offset | | UTC | No | No | Yes | Throw away | | UTC | No | No | No | Throw away | | Local | Yes | Yes | Yes | Map to UTC+offset with optional correction | @@ -70,7 +70,7 @@ For IEEE 11073-10206 timestamps the following table can be used: | Local | Yes | No | Yes | Map to PHG timeline, including PHG offset | | Local | Yes | No | No | Map to PHG timeline, including PHG offset | | Local | No | Yes | Yes | Map to UTC+offset | -| Local | No | Yes | No | Map to UTC, optionally include PHG offset | +| Local | No | Yes | No | Map to UTC, include PHG offset | | Local | No | No | Yes | Throw away | | Local | No | No | No | Throw away | | Tick counter | Yes | n.a. | n.a. | Map to PHG timeline, including PHG offset | diff --git a/input/intro-notes/StructureDefinition-PhdDevice-notes.md b/input/intro-notes/StructureDefinition-PhdDevice-notes.md index f4c845a..4056509 100644 --- a/input/intro-notes/StructureDefinition-PhdDevice-notes.md +++ b/input/intro-notes/StructureDefinition-PhdDevice-notes.md @@ -26,7 +26,7 @@ An example of a system identifier is: {% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON EXCEPT:identifier %} ### UDI → Device.udiCarrier -The UDI is included as an optional attribute of a PHD in the IEEE 11073-10206 ACOM standard (and the older IEEE 11073-20601 standard). It is also supported in the Bluetooth SIG Device Information Service and the GHS Profile. The UDI elements supported are issuer, jurisdiction, Device Identifier, and the Human Readable Barcode String. The udiCarrier does have elements for each of these entries. There is no appropriate entryType code for this sourcing of the UDI in FHIR R4 and the code `unknown` should be used. In FHIR R5 the code `electronic-transmission` can be used. +The UDI is included as an optional attribute of a PHD in the IEEE 11073-10206 ACOM standard (and the older IEEE 11073-20601 standard). It is also supported in the Bluetooth SIG Device Information Service and the GHS Profile. The UDI elements supported are issuer, jurisdiction, Device Identifier, and the Human Readable Barcode String. The udiCarrier does have elements for each of these entries. The entryType code for this sourcing of the UDI `electronic-transmission` is used as the UDI is transmitted electronically. The UDI of a device consists of a Device Identifier (DI) and a Production Identifier (PI). The DI is the part of the UDI that identifies the specific model of the device. The PI is used to identify the specific instance of the device, such as its serial number or lot number. When the PI includes a serial number it identifies a specific instance of the devices of the model as specified by the DI. diff --git a/input/pagecontent/CodeableConcepts.md b/input/pagecontent/CodeableConcepts.md index 99e8da5..bc02a0b 100644 --- a/input/pagecontent/CodeableConcepts.md +++ b/input/pagecontent/CodeableConcepts.md @@ -1,4 +1,4 @@ -In this guide there will be several instances where the IEEE 11073-10101 nomenclature (MDC) codes are mapped to FHIR. In almost all cases this mapping involves an element that is a CodeableConcepts data type. The mapping is as follows: +In this guide there will be several instances where the IEEE 11073-10101 nomenclature (MDC) codes are mapped to FHIR. In almost all cases this mapping involves an element that is a `CodeableConcepts` data type. The mapping is as follows: - `CodeableConcept.coding.code` = *partition* * 2<sup>16</sup> + *term code* - `CodeableConcept.coding.system` = urn:iso:std:iso:11073:10101 @@ -8,4 +8,4 @@ The reference identifier in the display element is optional since the uploader m The display element itself is also optional for future compatibility. Any display element entry requires that the uploader have previous knowledge of the code as display information is not provided by protocol. -The text element can also used to provide additional information about the used code. An option is that the text element is populated with *"reference identifier: optional additional implementation-defined text describing the code which may be in the local language*". For example, "MDC_CTXT_GLU_MEAL: Meal associated with measurement". +The `text` element can also used to provide additional information about the used code. An option is that the `text` element is populated with the reference identifier followed by additional implementation-defined text describing the code which may be in the local language. For example, `"MDC_CTXT_GLU_MEAL: Meal associated with measurement"`. diff --git a/input/pagecontent/CoincidentTimeStamp.md b/input/pagecontent/CoincidentTimeStamp.md index 79a76c6..b1d7b6d 100644 --- a/input/pagecontent/CoincidentTimeStamp.md +++ b/input/pagecontent/CoincidentTimeStamp.md @@ -1,23 +1,23 @@ In remote patient monitoring, data can arrive to the health care provider from any location on the planet. Given that PHDs can be unsynchronized, or have time clocks set by the user, or default factory times, or no time clock at all, and no time zone information, providing accurate timestamps to the health care provider is a challenge. The Coincident Timestamp Observation provides a mechanism to report the PHD clock status and links it to the timeline of the PHG. -The Coincident Timestamp is a measurement taken by the PHG of the current time of the PHD at the current time of the PHG. If the PHG is better synchronized to NTP (Network Time Protocol) time than the PHD, the PHG corrects the measurement times reported by the PHD by the difference between the two timelines. In other words, the PHG places the measurements on its timeline. A PHG compliant to this IG shall have the capability to synchronize to UTC and shall support a local time and DST offset. This enables a PHG to set the PHD's clock to a synchronized state. +The Coincident Timestamp is a measurement taken by the PHG of the current time of the PHD at the current time of the PHG. If the PHG is better synchronized, e.g., to NTP (Network Time Protocol), than the PHD, the PHG corrects the measurement times reported by the PHD by the difference between the two timelines. In other words, the PHG places the measurements on its timeline. A PHG compliant to this IG shall have the capability to synchronize to UTC and shall support a local time and DST offset. This enables a PHG to set the PHD's clock to a synchronized state. The time capabilities of the PHD and PHG are in the PHD Device and PHG Device resource property elements, respectively. The status of the PHD clock is present in the data elements of the Coincident Timestamp. From these elements one can determine whether the PHG or PHD is better synchronized. ### Coincident Timestamp Basics -The coincident timestamp is a measurement of the current time of the PHD at the current time of the PHG. PHD Observation resources reference the Coincident Timestamp Observation in the Observation.extension.valueReference element in the [Coincident Timestamp Reference extension](StructureDefinition-CoincidentTimeStampReference.html) +The coincident timestamp is a measurement of the current time of the PHD at the current time of the PHG. PHD Observation resources reference the Coincident Timestamp Observation in the `Observation.extension.valueReference` element in the [Coincident Timestamp Reference extension](StructureDefinition-CoincidentTimeStampReference.html) -The PHG uses the following logic to report Coincident Timestamps and to adjust PHD observation timestamps under the assumption that PHD and PHG have the same UTC time zone and DST offset: +The PHG uses the following logic to report Coincident Timestamps and to adjust PHD observation timestamps under the assumption that PHD and PHG are close to each other and hence have the same UTC time zone and DST offset: - If the PHD does **not** report timestamps in a measurement - there is no Coincident Timestamp Observation for the measurement - *the PHG uses the time of reception as the measurement timestamp* -- If the PHD measurement does report a timestamp that **is not** from its current timeline: - - The time of the PHG is reported in the Coincident Timestamp Observation.effectiveDateTime element - - The Coincident Timestamp Observation.value[x] element is empty - - The Coincident Timestamp dataAbsentReason is set to "unknown" +- If the PHD measurement does report a timestamp that is **not** from its current timeline: + - The time of the PHG is reported in the Coincident Timestamp `Observation.effectiveDateTime` element + - The Coincident Timestamp `Observation.value[x]` element is empty + - The Coincident Timestamp `dataAbsentReason` is set to `unknown` - If the PHD measurement timestamp contains a UTC or local time and reports being externally synchronized - - *The PHG reports the timestamps of the PHD measurement, corrected for time zone and DST offset as needed* + - *The PHG reports the timestamps of the PHD measurement, only corrected for time zone and DST offset as needed* - Else - The PHD measurement times stamp reports a tick counter (releative time) or reports not being externally synchronized - The PHG is unable to produce a meaningful timestamp for the measurement @@ -25,24 +25,24 @@ The PHG uses the following logic to report Coincident Timestamps and to adjust P - If the PHD measurement does report a timestamp that **is** from its current timeline: - If the PHD measurement timestamp contains a UTC or local time and reports being externally synchronized - If the PHG is better synchronized than the PHD - - The current time of the PHG is reported in the Observation.effectiveDateTime element - - The current time of the PHD is reported in the Observation.valueDateTime element + - The current time of the PHG is reported in the `Observation.effectiveDateTime` element + - The current time of the PHD is reported in the `Observation.valueDateTime` element - *The PHG corrects the measurement timestamps from the PHD's current timeline by the difference* - If the PHD is better synchronized than the PHG - - The current time of the PHG is not reported and the Observation.effectiveDateTime element is empty - - The current time of the PHD is reported in the Observation.valueDateTime element + - The current time of the PHG is not reported and the `Observation.effectiveDateTime` element is empty + - The current time of the PHD is reported in the `Observation.valueDateTime` element - *The PHG reports the timestamps of the PHD measurement, corrected for time zone and DST offset as needed* - Else - The PHD observation contains a tick counter (releative time) or is not externally synchronized - - The time of the PHG is reported in the Observation.effectiveDateTime element - - The corresponding time of the PHD is reported in the Observation.valueDateTime or Observation.valueQuantity element + - The time of the PHG is reported in the `Observation.effectiveDateTime` element + - The corresponding time of the PHD is reported in the `Observation.valueDateTime` or `Observation.valueQuantity` element - *The PHG maps the PHD measurement timestamp to its own timeline by using the Coincident Timestamp as a anchor point between the two timelines* -``` + As an example, say the PHG reads the current time of the PHD and sees that it is six minutes behind it's time. If the PHG is better synchronized to NTP, the PHG will add six minutes to all the timestamps reported by the PHD on its current timeline. ### Mapping Tick Counters -PHDs may also use tick counters of a specified resolution that report a tick count or relative time. GHS supports resolutions of 1 second to 100 microseconds. With relative times there is no check for which device is better synchronized. The PHG must always map the value to UTC plus offset. The PHD's current time is reported in the Observation.valueQuantity element scaled to the tick counter's resolution. This time provides the anchor time allowing the PHG to map the relative times reported in measurements to its own timeline in UTC plus offset format. +PHDs may also use tick counters of a specified resolution that report a tick count or relative time. GHS supports resolutions of 1 second to 100 microseconds. With relative times there is no check for which device is better synchronized. The PHG must always map the value to UTC plus offset. The PHD's current time is reported in the `Observation.valueQuantity` element scaled to the tick counter's resolution. This time provides the anchor time allowing the PHG to map the relative times reported in measurements to its own timeline in UTC plus offset format. A relative timestamp value in a measurement is mapped to UTC plus offset by taking the difference between the measurement timestamp and the synchronisation point's relative time. That difference is added to the synchronisation point's UTC time plus offset. For example, if the PHD is using the 1 millisecond relative time and the PHG obtains the current relative time 'anchor' value of 100000 at the PHG's current time 'anchor' value of 2017/11/27 05:31:44.555 -0500 then the PHG can map a measurement timestamp of 108000 to an actual time of 2017/11/27 05:31:52.555 -0500 since 108000 - 100000 = 8000 milliseconds. diff --git a/input/pagecontent/ObtainObservationCode.md b/input/pagecontent/ObtainObservationCode.md index 7924ffa..26cf8cc 100644 --- a/input/pagecontent/ObtainObservationCode.md +++ b/input/pagecontent/ObtainObservationCode.md @@ -3,7 +3,7 @@ The Observation.code element is populated as follows: * if the application wishes to transcode this MDC code into other coding systems the application is free to do so but * the MDC code shall be present in a coding element - * if the code matches one of the [FHIR observation-vitalsigns codes](https://hl7.org/fhir/R4/observation-vitalsigns.html), the observation-vitalsigns code shall be present in a coding element + * if the code matches one of the [FHIR observation-vitalsigns codes]({{ site.data.fhir.path }}observation-vitalsigns.html), the observation-vitalsigns code shall be present in a coding element * any other coding translations desired may be placed in an additional coding element. * for the MDC code the mapping is as follows: * Observation.code.coding.code = *value* diff --git a/input/pagecontent/ProfileConsumers.md b/input/pagecontent/ProfileConsumers.md index 4fade20..f00b695 100644 --- a/input/pagecontent/ProfileConsumers.md +++ b/input/pagecontent/ProfileConsumers.md @@ -9,7 +9,7 @@ It is important to understand that this Implementation Guide (IG) assumes that t PHGs following this IG use the following FHIR resources: Patient, Device, DeviceMetric and Observation. A Device resource is used for the PHG properties and a second Device resource is used for the PHD properties. Observation resources are used for each measurement and for the [Coincident Timestamp](CoincidentTimeStamp.html). -Understanding the content of the FHIR resources specified in this IG should be straight forward. Familiarity with the [MDC](https://terminology.hl7.org/MDC.html) coding system is the only IEEE 11073 domain-specific knowledge required. In addition, there are a few extensions used in the PHD-related profiles. [One](https://www.hl7.org/fhir/R4/extension-observation-gatewaydevice.html) supports a reference to the Personal Health Gateway (PHG) Device resource in the PHD Observation profiles. A PHG is the unit that is typically responsible for communicating with the PHD and encoding that data into FHIR. It may be a mobile phone, a PC, or a dedicated set-top box. [Another](StructureDefinition-CoincidentTimeStampReference.html) supports linking the timelines of the PHG and the PHD via a [Coincident Timestamp](CoincidentTimeStamp.html) Observation. +Understanding the content of the FHIR resources specified in this IG should be straight forward. Familiarity with the [MDC](https://terminology.hl7.org/MDC.html) coding system is the only IEEE 11073 domain-specific knowledge required. In addition, there are a few extensions used in the PHD-related profiles. [One]({{ site.data.fhir.path }}extension-observation-gatewaydevice.html) supports a reference to the Personal Health Gateway (PHG) Device resource in the PHD Observation profiles. A PHG is the unit that is typically responsible for communicating with the PHD and encoding that data into FHIR. It may be a mobile phone, a PC, or a dedicated set-top box. [Another](StructureDefinition-CoincidentTimeStampReference.html) supports linking the timelines of the PHG and the PHD via a [Coincident Timestamp](CoincidentTimeStamp.html) Observation. The next sections discuss the resources generated by PHGs following this IG. @@ -29,7 +29,7 @@ Every PHD generated measurement Observation resource contains the following info |IEEE 11073-10206 Observation attribute|FHIR Observation data element|Description| |---|---|---| -|type|`code`|This element tells you what the measurement is. There should be a coding element using the MDC coding system.<br>If a vital sign, there will be an additional coding element using one of the [LOINC vital sign codes](https://hl7.org/fhir/R4/valueset-observation-vitalsignresult.html).| +|type|`code`|This element tells you what the measurement is. There should be a coding element using the MDC coding system.<br>If a vital sign, there will be an additional coding element using one of the [LOINC vital sign codes]({{ site.data.fhir.path }}valueset-observation-vitalsignresult.html).| ||`category`|The category element is present with at least the value `"phd"`. For vital signs, there will also be another element with value `"vital-signs"` as required by the vital signs profile. |measurement-status|`Observation.status`,<br> `Observation.dataAbsentReason`|This element tells what the status of the measurements is and has usually the value `final`. In error cases the data-absent-reason element is filled with an appropriate value. |timestamp|`Observation.effectiveDateTime`,<br/>`Observation.effectivePeriod`|This element tells when the measurement occurred, and is a point in time or a period with a start- and end-time.| @@ -46,16 +46,16 @@ MDC codes are available from the [Rosetta Terminology Mapping Management Service For those consumer applications that would like to have the codes as LOINC and the uploader did not provide them, a mapping table between MDC and LOINC is also included in LOINC since v2.54 [available here](https://loinc.org/news/loinc-version-2-54-and-relma-version-6-12-available/). The FHIR MDC to LOINC concept map is available [here](https://fhir.loinc.org/ConceptMap/?url=http://loinc.org/cm/loinc-to-ieee-device-codes). One may freely download and use this material as needed in an implementation, but it does require a (free) login account. A mapping from MDC to SNOMED CT for some of the more common codes is available in the somewhat outdated Continua Design Guidelines [H.813 HIS Interface](https://www.itu.int/rec/T-REC-H.813-201911-I) document. The guidelines are freely available for download, however [licensing requirements](https://www.snomed.org/licensing) for the use of the SNOMED CT code system apply. -FHIR (R4) requires that a LOINC code is present if the measurement is one of the vital signs given [here](https://hl7.org/fhir/R4/observation-vitalsigns.html). In that case, the `Observation.code` shall have at least a second coding element containing a LOINC code. *The consumer must be aware that the MDC-to-LOINC mapping may be many to one*. For example, both the pulse rate obtained from a Blood Pressure Cuff (149546) and the pulse rate obtained from a Pulse Oximeter (149530) may be mapped to the LOINC code (8867-4). A PHG may map these MDC codes also to more specific LOINC codes. +FHIR requires that a LOINC code is present if the measurement is one of the vital signs given [here]({{ site.data.fhir.path }}observation-vitalsigns.html). In that case, the `Observation.code` shall have at least a second coding element containing a LOINC code. *The consumer must be aware that the MDC-to-LOINC mapping may be many to one*. For example, both the pulse rate obtained from a Blood Pressure Cuff (149546) and the pulse rate obtained from a Pulse Oximeter (149530) may be mapped to the LOINC code (8867-4). A PHG may map these MDC codes also to more specific LOINC codes. In addition to the LOINC code, FHIR requires an `Observation.code` element with value "vital-signs" when the measurement is a vital sign. #### The Timestamp: Observation.effective[x] -All measurements contain a timestamp which is either an instant in time, a dateTime data type, or a period of time, a Period data type. The period has both a start and end. Results of a workout session are a common type of measurement with a period. The 'instant' data type is not used as it is permissible for PHDs to report time at resolutions greater than a day in which case there is no time zone. An activity monitor reporting only daily summaries could be an example of a PHD using such a resolution. +All measurements contain a time stamp which is either an instant in time (a `dateTime` data type), or a period of time (a `Period` data type). A period reported by a PHD has both a start and an end. Results of a workout session are a common type of measurement with a period. The `dateTime` data type is chosen as it is permissible for PHDs to report time at resolutions greater than a day in which case there is no time zone. An activity monitor reporting only daily summaries could be an example of a PHD using such a time resolution. All timestamps with resolutions finer than a day contain the offset to UTC. If the offset is -00:00, it means that the offset to local time is not known, and what is being reported is UTC time, even though the measurement is taken in Japan. If the offset is +00:00, it means the offset IS known; the measurement just happens to be in a time zone that is UTC. -Below is an example of the effective[x] when the timestamp is an instant in time: +Below is an example of the `effective[x]` when the timestamp is an instant in time: {% fragment Observation/temperature-observation JSON EXCEPT:effectiveDateTime %} @@ -205,7 +205,7 @@ IEEE 11073-20601 does only support compound measurements with numeric components |`Observation.component.valueQuantity.code`|the units (as UCUM)| |`Observation.component.valueQuantity.system="http://unitsofmeasure.org"`|UCUM code system identifier| -Note that the `Observation.code` element is subject to the same FHIR LOINC code requirement as the `Observation.code` element if the component is one of the vital signs [here](https://hl7.org/fhir/R4/observation-vitalsigns.html). The Systolic and Diastolic pressures are in that list, but the MEAN component is not. +Note that the `Observation.code` element is subject to the same FHIR LOINC code requirement as the `Observation.code` element if the component is one of the vital signs [here]({{ site.data.fhir.path }}observation-vitalsigns.html). The Systolic and Diastolic pressures are in that list, but the MEAN component is not. An example of a Blood Pressure measurement would be as follows: @@ -377,7 +377,7 @@ There are several Device elements that are just basic strings. Their meanings ar - `Device.partNumber` #### Device Type -This field states that the device is a PHD. There is no code in the list of device types provided by FHIR [here](https://hl7.org/fhir/R4/valueset-device-type.html) that indicates a personal health device. Instead we use the MDC code that indicates a simple MDS (Medical Device System) object. This entry will be identical for all PHDs following this IG. It appears as follows: +This field states that the device is a PHD. There is no code in the list of device types provided by FHIR [here]({{ site.data.fhir.path }}valueset-device-type.html) that indicates a personal health device. Instead we use the MDC code that indicates a simple MDS (Medical Device System) object. This entry will be identical for all PHDs following this IG. It appears as follows: {% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON EXCEPT:type %} From 5c03a2c9d6c92426f937007035a8f64dbbb4b394 Mon Sep 17 00:00:00 2001 From: Erik Moll <erik.moll@philips.com> Date: Sun, 20 Jul 2025 15:29:33 +0200 Subject: [PATCH 03/10] further Jira tickets applied --- FHIR-phd.xml | 5 +- input-cache/schemas/R5/fhir-single.xsd | 2 +- input/PhdImplementationGuide.xml | 7 +- input/fsh/StructureDefinition.PhdDevice.fsh | 2 +- .../fsh/ValueSet.MDCClockResolutionTypes.fsh | 2 +- ...tureDefinition-PhdBaseObservation-intro.md | 3 +- ...tureDefinition-PhdBaseObservation-notes.md | 39 +++--- ...eDefinition-PhdNumericObservation-notes.md | 16 +-- input/pagecontent/Appendix.md | 17 ++- .../CompoundNumericObservationProfile.md | 61 ---------- input/pagecontent/DIMtoFHIRMapping.md | 113 ++++++++---------- input/pagecontent/DIMtoFHIRMappingDetails.md | 3 +- ...> GeneratingtheTimeStampPartIdentifier.md} | 6 +- input/pagecontent/ObservationIdentifier.md | 7 -- input/pagecontent/ObtainObservationCode.md | 17 +-- input/pagecontent/ProfileConsumers.md | 47 ++------ .../TechnicalImplementationGuidance.md | 3 +- 17 files changed, 122 insertions(+), 228 deletions(-) delete mode 100644 input/pagecontent/CompoundNumericObservationProfile.md rename input/pagecontent/{GeneratingtheReportedTimeStampIdentifier.md => GeneratingtheTimeStampPartIdentifier.md} (67%) delete mode 100644 input/pagecontent/ObservationIdentifier.md diff --git a/FHIR-phd.xml b/FHIR-phd.xml index a94f985..bdcbb36 100644 --- a/FHIR-phd.xml +++ b/FHIR-phd.xml @@ -130,7 +130,8 @@ <page deprecated="true" key="phdExample" name="Device example from a Blood Pressure PHD"/> <page deprecated="true" key="downloads" name="Downloads"/> <page deprecated="true" key="GeneralNotestoConsumers" name="General Notes to Consumers of FHIR Data"/> -<page key="GeneratingtheReportedTimeStampIdentifier" name="Generating the PHD Reported Timestamp Identifier"/> +<page deprecated="true" key="GeneratingtheReportedTimeStampIdentifier" name="Generating the PHD Reported Time Stamp Identifier"/> +<page key="GeneratingtheTimeStampPartIdentifier" name="Generating the PHD Reported Timestamp Identifier"/> <page deprecated="true" key="ContinuaPersonalAreaNetworkCodes" name="Generating the PHD codes"/> <page key="GenericModel" name="Generic and Extensible Model"/> <page key="Glossary" name="Glossary"/> @@ -167,7 +168,7 @@ <page deprecated="true" key="spotNumeric" name="Simple numeric with supplemental types"/> <page key="toc" name="Table of Contents"/> <page deprecated="true" key="terminology" name="Terminology"/> -<page key="ObservationIdentifier" name="The Unique Observation Identifier"/> +<page deprecated="true" key="ObservationIdentifier" name="The Observation Identifier"/> <page key="UseCases" name="Use Cases"/> <page deprecated="true" key="languages" name="languages" url="languages"/> </specification> \ No newline at end of file diff --git a/input-cache/schemas/R5/fhir-single.xsd b/input-cache/schemas/R5/fhir-single.xsd index b1284fa..d0d04bc 100644 --- a/input-cache/schemas/R5/fhir-single.xsd +++ b/input-cache/schemas/R5/fhir-single.xsd @@ -47,7 +47,7 @@ POSSIBILITY OF SUCH DAMAGE. - Generated on Fri, Jul 18, 2025 15:40+0000 for FHIR v6.0.0-ballot2 + Generated on Fri, Jul 18, 2025 20:50+0000 for FHIR v6.0.0-ballot2 --> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://hl7.org/fhir" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns:xml="http://www.w3.org/XML/1998/namespace" targetNamespace="http://hl7.org/fhir" elementFormDefault="qualified" version="6.0.0-ballot2"> <!-- Note: When using this schema with some tools, it may also be necessary to declare xmlns:xml="http://www.w3.org/XML/1998/namespace", however this causes performance issues with other tools and thus is not in the base schemas. --> diff --git a/input/PhdImplementationGuide.xml b/input/PhdImplementationGuide.xml index 72d615f..976d6f0 100644 --- a/input/PhdImplementationGuide.xml +++ b/input/PhdImplementationGuide.xml @@ -627,12 +627,7 @@ In this example there are only xml structure definitions, value sets, code syste <generation value="markdown"/> </page> <page> - <nameUrl value="ObservationIdentifier.html"/> - <title value="The Unique Observation Identifier"/> - <generation value="markdown"/> - </page> - <page> - <nameUrl value="GeneratingtheReportedTimeStampIdentifier.html"/> + <nameUrl value="GeneratingtheTimeStampPartIdentifier.html"/> <title value="Generating the PHD Reported Timestamp Identifier"/> <generation value="markdown"/> </page> diff --git a/input/fsh/StructureDefinition.PhdDevice.fsh b/input/fsh/StructureDefinition.PhdDevice.fsh index 80c5d38..c0b560e 100644 --- a/input/fsh/StructureDefinition.PhdDevice.fsh +++ b/input/fsh/StructureDefinition.PhdDevice.fsh @@ -153,7 +153,7 @@ Description: "Profile for the Device Resource for a PHD" * ^definition = "If bit is set, code contains Y if cleared, N" * property[clockResolutionProperty] ^short = "Clock Resolution as reported by the PHD" - * ^definition = "For each Boolean clock capability reported by a PHD a property element is used." + * ^definition = "The clock resolution as reported by the PHD in microseconds." * type from MDCClockResolutionTypes (required) * ^short = "Tells what the clock resolution type is" * ^definition = "The resolution of the clock as reported by the PHD." diff --git a/input/fsh/ValueSet.MDCClockResolutionTypes.fsh b/input/fsh/ValueSet.MDCClockResolutionTypes.fsh index bf06649..856b135 100644 --- a/input/fsh/ValueSet.MDCClockResolutionTypes.fsh +++ b/input/fsh/ValueSet.MDCClockResolutionTypes.fsh @@ -13,4 +13,4 @@ Description: "ValueSet for the ISO/IEEE 11073-10101 Nomenclature Codes for Clock * Mdc#68223 * Mdc#68224 * Mdc#68239 -//* Mdc#68229 \ No newline at end of file +* Mdc#68229 \ No newline at end of file diff --git a/input/intro-notes/StructureDefinition-PhdBaseObservation-intro.md b/input/intro-notes/StructureDefinition-PhdBaseObservation-intro.md index f1a6794..96a34a2 100644 --- a/input/intro-notes/StructureDefinition-PhdBaseObservation-intro.md +++ b/input/intro-notes/StructureDefinition-PhdBaseObservation-intro.md @@ -9,6 +9,7 @@ The PHD Base Observation profile contains the elements that are common to all PH - category: a fixed value identifying observations generated by PHDs - measurement status - gatewayDevice extension: reference to the PHG responsible for generating the upload - - coinincidentTimestamp extension: reference to the coincidentTimestamp observation that relates PHD time and PHG time + - coincidentTimestamp extension: reference to the coincidentTimestamp observation that relates PHD time and PHG time - performer: optional, when the patient is known to be the performer this may refer to the patient + - identifier: the PHD conditional-create identifier for this measurement to avoid duplicate uploads diff --git a/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md b/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md index f6c23b5..1266954 100644 --- a/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md +++ b/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md @@ -3,25 +3,24 @@ The following sections give more details on the data elements in a PHDBaseObserv ### Gateway Device extension HL7 has defined an extension for the Observation resource to reference a gateway device. This extension is used to reference the Device resource representing the Personal Health Gateway (PHG) device. -### Unique Observation Identifier - prevention of data duplication -The *PHD Observation Identifier* is defined to prevent data duplication. It can be used as the selection criterion in the conditional create when uploading observations. +### Conditional-create Identifier - prevention of data duplication +The *Conditional-create Identifier* is defined to prevent data duplication. It can be used as the selection criterion in the conditional create when uploading observations. Ideally the PHG will implement a duplication detection mechanism and filter out any observations that have already been uploaded. One possible mechanism is to record the latest timestamp of any observation received during a connection. Then for a given device and patient and upload destination, on a subsequent connection the PHG can filter out any observations with a timestamp earlier than the recorded latest timestamp of the previous connection. The latest timestamp is then updated given the information received during the current connection. This filter not only saves the server from handling the conditional update transaction but saves bandwidth and upload costs. -Additionally a globally unique identifier can be used in combination with a conditional create operation to prevent duplication of observations on the server. -The identifier is a concatenated string of elements that contain sufficient information to uniquely identify the observation. The identifier is the concatenation of the device identifier, patient identifier, the ***PHD*** timestamp of the observation, the observation type code, the measurement duration if present, and the list of Supplemental-Types codes if any. Each entry is separated by a dash (-). It is important to use the timestamp of the PHD and not the potentially modified timestamp placed in the Observation.effective[x] element. Two PHGs may have slightly different times which would allow an undesired duplicate observation to appear. Note that for this scheme to work PHDs should NOT change the timestamp of a generated observation. +Additionally a globally unique identifier can be used in combination with a conditional create operation to prevent duplication of observations on the server when multiple PHGs can upload observations from the same PHD. The identifier is a concatenated string of elements that contain sufficient information to uniquely identify the observation. The identifier is the concatenation of the device identifier, patient identifier, the *PHD* timestamp of the observation, the observation type code, the measurement duration if present, and the list of Supplemental-Types codes if any. Each entry is separated by a dash (-). It is important to use the timestamp of the PHD and not the potentially modified timestamp placed in the Observation.effective[x] element. Two PHGs may have slightly different times which would allow an undesired duplicate observation to appear. Note that for this scheme to work PHDs should NOT change the timestamp of a generated observation. |Entry|value|Additional information| |---|---|---| -|device|`PHD Device.identifier.value`|This value is the PHD IEEE EUI-64 system identifier (16 hexadecimal characters)| +|device|`PHD Device.identifier.value`|This value is a hexadecimal representation of the PHD system identifier (16 hexadecimal characters for the IEEE EUI-64 identifier, 12 for the EUI-48 transport address identifier)| |patient|`Patient.identifier.value`-`Patient.identifier.system` or<br/>provided logical id|The dashes are part of the identifier. <br/>When the service provider gives the PHG a pre-determined patient logical id the PHG creates no Patient resource and has no patient information. In that situation the provided logical id is used| |type|`Observation.code.coding.code`|See [Obtaining the Observation.code](ObtainObservationCode.html) (decimal number)| -|timestamp|`Observation.effectiveDateTime` or `Observation.effectivePeriod.start`|The reported PHD timestamp. See [Generating the PHD Reported Timestamp](GeneratingtheReportedTimeStampIdentifier.html)| -|duration|the length of `Observation.effectivePeriod`| See [Generating the PHD Reported Timestamp](GeneratingtheReportedTimeStampIdentifier.html)| +|timestamp|`Observation.effectiveDateTime` or `Observation.effectivePeriod.start`|The reported PHD timestamp. See [Generating the PHD Reported Timestamp](GeneratingtheTimeStampPartIdentifier.html)| +|duration|the length of `Observation.effectivePeriod`| See [Generating the PHD Reported Timestamp](GeneratingtheTimeStampPartIdentifier.html)| |Supplemental Information|`Observation.component.valueCodeableConcept.coding.code` |A sequence of MDC codes (decimal number) separated by a dash from the "supplemental information" components.| The final identifier is made by concatenating the entries above as follows: - - *device*-*patient*-*type*-*value*-*timestamp*-*duration*-*Supplemental Information* + - *device*-*patient*-*type*-*timestamp*-*duration*-*Supplemental Information* All PHGs compliant to this IG should implement this identifier in the same manner. Compliance assures that even if the patient uploads the same observation to the same server from a different PHG, a duplicate of the observation will not be generated on the server. This is important since some PHDs do not provide a means of deleting stored and uploaded observations and will upload old observations again with each new addition of a observation as much as device storage allows. @@ -35,7 +34,7 @@ One obtains the IEEE 11073-10101 observation type for the code element in the sa The subject element normally points to the PhdPatient resource using the logical id of the Patient resource, for example 'Patient/123546'. For device settings known to the PHG it should point to the PHD. ### Performer -In situations where the gateway knows that the patient is the person performing the measurement, a Observation.performer element can also point to the PhdPatient resource. However, in most situations this is unknown and the performer is not filled in. And for coincident timestamp observations, the performer should not be provided. This profile puts no constraints on the performer element. +In situations where the gateway knows that the patient is the person performing the measurement, a `Observation.performer` element can also point to the PhdPatient resource. However, in most situations this is unknown and the performer is not filled in. And for coincident timestamp observations, the performer should not be provided. This profile puts no constraints on the performer element. ### Timestamp: effective[x] PHDs report timestamps in various methods and may not report timestamps at all. The PHG will include a timestamp in every observation that is uploaded using a conversion as needed based on the timestamp data received from the PHD. The timestamp types and corresponding PHG conversions are summarized below: @@ -76,11 +75,11 @@ For IEEE 11073-10206 timestamps the following table can be used: | Tick counter | Yes | n.a. | n.a. | Map to PHG timeline, including PHG offset | | Tick counter | No | n.a. | n.a. | Throw away | -The PHG maps the 'converted' timestamp to either an Observation.effectiveDateTime element or an Observation.effectivePeriod element. The second situation occurs when the metric observation includes a Measurement-Duration (duration) attribute. Then the timestamp attribute gives the start of the period and the end of the period is obtained by adding the Measurement-Duration value to it. If no timestamp is provided, the PHG, using the time of reception of the observation as its timestamp must then do the reverse; the time of reception is the end time and the start time is given by subtracting the Measurement-Duration value from it. +The PHG maps the 'converted' timestamp to either an `Observation.effectiveDateTime` element or an `Observation.effectivePeriod` element. The second situation occurs when the metric observation includes a Measurement-Duration (duration) attribute. Then the timestamp attribute gives the start of the period and the end of the period is obtained by adding the Measurement-Duration value to it. If no timestamp is provided, the PHG, using the time of reception of the observation as its timestamp must then do the reverse; the time of reception is the end time and the start time is given by subtracting the Measurement-Duration value from it. When the PHG modifies an Observation's timestamp as received from the PHD it shall also generate a Coincident Timestamp observation that records how the Observation.effective[x] element is generated. ### Device -The Observation.device element is a reference to the Device resource representing the PHD that generated the observation. +The `Observation.device` element is a reference to the Device resource representing the PHD that generated the observation. ### extension: Coincident timestamp reference This extension references Coincident Timestamp Observation resource that relates the PHD and PHG timelines. This occurs whenever the observation reported by the PHD has a timestamp. The Coincident Timestamp Observation reports how this Observation.effective[x] element is generated. @@ -114,7 +113,7 @@ The Supplemental Information attribute contains a list of one or more MDC codes <strong>Should we move Supplemental Type information to an extension?</strong> In the PHD IG v1.0 an attempt was made to avoid extensions as much as possible. In this version we are using extensions for less often used elements of the IEEE 11073-10206 model and in places were the conceptual models from PHD and FHIR model are too different to have a 1-1 mapping between data elements of these models. - The question is if this applies to Supplemental Type information as well. Should IEEE 11073-10206/20601 Supplemental Information be modeled as a FHIR Observation.component or as an extension in FHIR? + The question is if this applies to Supplemental Type information as well. Should IEEE 11073-10206/20601 Supplemental Information be modeled as a FHIR `Observation.component` or as an extension in FHIR? Input is welcome. </blockquote> @@ -131,16 +130,16 @@ The table below lists the error conditions and the FHIR data elements to which t | IEEE 11073-10206 Measurement Status | FHIR Observation Resource Data Element | Further Remarks Options | | ---------------------- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | -| Invalid | dataAbsentReason = DAR#error<br/> status = HL7Status#entered-in-error | A device or gateway could decide not to upload invalid observations and could report an error by other means. | -| Questionable | interpretation = PoCDStatus#questionable | \- | -| Not-available | dataAbsentReason = DAR#not-performed | A device or gateway could decide not to upload observations with no value and could report an error by other means. | -| Calibrating | interpretation = PoCDStatus#calibration-ongoing | \- | -| Test-data | meta.security = ActReason#HTEST | Test data should in most cases not be uploaded to a FHIR server, except for testing purposes. | -| Early-estimate | interpretation = PoCDStatus#early-indication<br/> status = HL7Status#preliminary| \- | +| Invalid | `dataAbsentReason` = DAR#error<br/> `status` = HL7Status#entered-in-error | A device or gateway could decide not to upload invalid observations and could report an error by other means. | +| Questionable | `interpretation` = PoCDStatus#questionable | \- | +| Not-available | `dataAbsentReason` = DAR#not-performed | A device or gateway could decide not to upload observations with no value and could report an error by other means. | +| Calibrating | `interpretation` = PoCDStatus#calibration-ongoing | \- | +| Test-data | `meta.security` = ActReason#HTEST | Test data should in most cases not be uploaded to a FHIR server, except for testing purposes. | +| Early-estimate | `interpretation` = PoCDStatus#early-indication<br/> `status` = HL7Status#preliminary| \- | | Manually-entered | \- | Add a note to the Observation resource that it was manually entered. | | Setting | \- | For device settings, the Observation resource should reference the PHD Device as the subject and not the Patient. | -| Threshold error | interpretation = PoCDStatus#in-alarm | Applies to numeric data. Add a note to the Observation resource that it is outside its boundaries. Should be used in combination with the SimpleAlerting Extension. | -| Thresholding disabled | interpretation = PoCDStatus#alarm-inhibited | Applies to numeric data. Add a note to the Observation resource that its boundaries are not checked. Should be used in combination with the SimpleAlerting Extension. | +| Threshold error | `interpretation` = PoCDStatus#in-alarm | Applies to numeric data. Add a note to the Observation resource that it is outside its boundaries. Should be used in combination with the SimpleAlerting Extension. | +| Thresholding disabled | `interpretation` = PoCDStatus#alarm-inhibited | Applies to numeric data. Add a note to the Observation resource that its boundaries are not checked. Should be used in combination with the SimpleAlerting Extension. | DAR: [Data Absent Reason CodeSystem](http://terminology.hl7.org/CodeSystem/data-absent-reason) HL7Status: [Observation Status CodeSystem]({{ site.data.fhir.path }}observation-status) diff --git a/input/intro-notes/StructureDefinition-PhdNumericObservation-notes.md b/input/intro-notes/StructureDefinition-PhdNumericObservation-notes.md index d7832c9..1a66e1d 100644 --- a/input/intro-notes/StructureDefinition-PhdNumericObservation-notes.md +++ b/input/intro-notes/StructureDefinition-PhdNumericObservation-notes.md @@ -1,7 +1,7 @@ This profile is used to map ACOM Numeric Observations. The measured value is reported as a floating number with an optional accuracy. In GHS the value is encoded as an IEEE 11073 FLOAT that indicates both precision and the number of significant digits. The `Observation.valueQuantity.value` element is required to honor the reported precision. See [Mder FLOATs and SFLOATs](MderFLOATsandSFLOATs.html) for instructions on handling S/FLOATs and their encoding to the valueQuantity . ### Mapping the unit code to FHIR -The MDC unit code as provided by the PHD needs to be mapped to UCUM. In most cases this mapping is straight forward, but there can be some examples which are tricky. The MDC_DIM_TICK for the RR interval is just the number of ticks. However, the tick unit is given by the Clock.time-resolution attribute which is the number of ticks per second. So if clock resolution is 0.5 ms and the RR measurement is 3000, that means the RR interval is 1.5 seconds. One could also express the measurement in Hertz. When the units are converted in this manner, the value must be converted appropriately. +The MDC unit code as provided by the PHD needs to be mapped to UCUM. See [Obtaining the Unit code]({{ output }}ObtainUnitCode.html) for details on how to obtain the unit code. <style>table, th, td { border: 1px solid black; @@ -60,17 +60,3 @@ The consumer of this profile does not need to concern itself with the mapping co | Sensor device | `Observation.device` | Points to the Device resource. | -### Try out of Jekyll/Liquid variables: - -| Variable Name | Liquid | Value | -|---------------|-------|--| -| path | page.path | {{ page.path }} | -| FHIR path | site.data.fhir.path | {{ site.data.fhir.path }} | -| FHIR version | site.data.fhir.version | {{ site.data.fhir.version }} | -| canonical | site.data.fhir.canonical | {{ site.data.fhir.canonical }} | -| ig | site.data.fhir.ig | {{ site.data.fhir.ig }} | -| igId | site.data.fhir.igId | {{ site.data.fhir.igId }} | -| ig.version | site.data.fhir.ig.version | {{ site.data.fhir.ig.version }} | -| ig.name | site.data.fhir.ig.name | {{ site.data.fhir.ig.name }} | -| ig.title | site.data.fhir.ig.title | {{ site.data.fhir.ig.title }} | -| ig.tx-server | site.data.fhir.ig.tx-server | {{ site.data.fhir.ig.tx-server }} | \ No newline at end of file diff --git a/input/pagecontent/Appendix.md b/input/pagecontent/Appendix.md index 3dd1a52..baf5b7c 100644 --- a/input/pagecontent/Appendix.md +++ b/input/pagecontent/Appendix.md @@ -36,4 +36,19 @@ A downloadable version of this IG is available so it can be hosted locally: ### Issues Reported issues can be found on the [HL7 FHIR PHD JIRA Dashboard](https://jira.hl7.org/secure/Dashboard.jspa?selectPageId=17103). -New issues can be reported there as well. \ No newline at end of file +New issues can be reported there as well. + +### Used Jekyll/Liquid variables: + +| Variable Name | Liquid | Value | +|---------------|-------|--| +| path | page.path | {{ page.path }} | +| FHIR path | site.data.fhir.path | {{ site.data.fhir.path }} | +| FHIR version | site.data.fhir.version | {{ site.data.fhir.version }} | +| canonical | site.data.fhir.canonical | {{ site.data.fhir.canonical }} | +| ig | site.data.fhir.ig | {{ site.data.fhir.ig }} | +| igId | site.data.fhir.igId | {{ site.data.fhir.igId }} | +| ig.version | site.data.fhir.ig.version | {{ site.data.fhir.ig.version }} | +| ig.name | site.data.fhir.ig.name | {{ site.data.fhir.ig.name }} | +| ig.title | site.data.fhir.ig.title | {{ site.data.fhir.ig.title }} | +| ig.tx-server | site.data.fhir.ig.tx-server | {{ site.data.fhir.ig.tx-server }} | \ No newline at end of file diff --git a/input/pagecontent/CompoundNumericObservationProfile.md b/input/pagecontent/CompoundNumericObservationProfile.md deleted file mode 100644 index 33b0f7e..0000000 --- a/input/pagecontent/CompoundNumericObservationProfile.md +++ /dev/null @@ -1,61 +0,0 @@ -The Compound Numeric Observation Profile is used when the PHD metric measurement is a vector or a set of related concepts which may be dimensionless. Examples would be the x, y, and z components of the acceleration, the systolic, diastolic, and mean components of a blood pressure measurement, or the set of package positions and associated questions in the Advanced Medication Monitor. Outside of the blood pressure, compound numeric measurements are relatively rare. - -The measurement is a compound when the PHD metric contains one of the following attributes: - -<style>table, th, td { -border: 1px solid black; -border-collapse:collapse; -padding: 6px;}</style> - -|Attribute|Value|Additional Information| -|- -|Compound-Basic-Nu-Observed-Value|set of 16-bit Mder SFLOATs|12-bit mantissa, 4-bit exponent| -|Compound-Simple-Nu-Observed-Value|set of 32-bit Mder FLOATs|24-bit mantissa, 8-bit exponent| -|Compound-Nu-Observed-Value|set of 32-bit Mder FLOATs|Complex attribute. Also contains<br/> metric-id<br/> measurement status<br/> unit-code| - -These attributes contain a measurement value that is described by a set of multiple numbers such as the x, y, and z components of an acceleration. It is NOT used to report an array of measurements but only where the quantity being measured requires more than one number to describe it. Each individual entry of the compound value is reported in an Observation.component element. The Mder SFLOAT and FLOAT encodings of each entry indicate both precision and the number of significant figures. The Observation.component.valueQuantity.value element is required to honor the reported precision as indicated by the Mder S/FLOAT. See the section [Mder FLOATs and SFLOATs](MderFLOATsandSFLOATs.html) for instructions on handling Mder S/FLOATs and their encoding to the valueQuantity. - -The Observation.component.code element is obtained from the Metric-Id-List attribute unless the measurement reported is a Compound-Nu-Observed-Value attribute. In that case the attribute itself has the metric type for each entry and that is used instead of the Metric-Id-List entries. The order of the entries in the Metric-Id-List are one-to-one with the order of the compound attribute entries. For example, if the Metric-Id-List in the Blood Pressure measurement has MDC codes for 'systolic", "diastolic" and "mean" in that order, the quantities in the compound attribute are the systolic, diastolic, and mean values, respectively. - -The Observation.code element comes from the Type attribute and gives the general type of measurement. For example, the Type attribute might indicate "acceleration" or "non-invasive blood pressure". There is no Observation.value[x] entry. There may still be an Observation.dataAbsentReason element if, say, the Measurement-Status attribute indicates an invalid or otherwise overall failure value. If there is such an overall failure of the measurement, then there is no need to report the components. - -The structure definition is given [here](StructureDefinition-PhdCompoundNumericObservation.html) - -### Mapping Compound Numerics to FHIR -The following table shows how the compound numeric attributes are mapped to FHIR. Since the FHIR Quantity also contains the units the Unit-Code attribute value is required to complete the picture. The MDC units need to be mapped to UCUM when used in FHIR. A UCUM unit shall be used when it is available. - -|Attribute|FHIR coding| -|- -|Compound-Basic-Nu-Observed-Value.*valueN*<br/>Unit-Code.*code*<br/>Metric-Id-List.*codeN*|Observation.component*N*.valueQuantity.value<br/>Observation.component*N*.valueQuantity.code (as UCUM)<br/>Observation.component*N*.code.coding.code| -|Compound-Simple-Nu-Observed-Value.*valueN*<br/>Unit-Code.*code*<br/>Metric-Id-List.*codeN*|Observation.component*N*.valueQuantity.value<br/>Observation.component*N*.valueQuantity.code (as UCUM)<br/>Observation.component*N*.code.coding.code -|Compound-Nu-Observed-Value.*valueN*<br/>Compound-Nu-Observed-Value.*unitN*<br/>Compound-Nu-Observed-Value.*metric-idN*<br/>Compound-Nu-Observed-Value.*statusN*|Observation.component*N*.valueQuantity.value<br/>Observation.component*N*.valueQuantity.code (as UCUM)<br/> Observation.component*N*.code.coding.code<br/>Observation.component*N*.dataAbsentReason| - -### Additional Numerical Measurement Information -IEEE 11073-20601 numeric metric measurements have some additional optional attributes that are used only for numerics. When they occur, these additional attributes provide further information about the measurement. An example of such a numeric-only additional attribute is one that describes the accuracy of the measurement. The accuracy is a measure of the deviation of the actual measurement from the reported measurement. Consequently, 'accuracy' is not a concept that makes any sense in the context of a measurement which is one or more of a finite set of enumerated codes such as a glucose-monitor meal association (breakfast, snack, fasting, etc.), and thus the attribute is not used in Enumeration metrics. - -As in the PhdBaseObservation profile, an Observation.component element is used to contain the additional information. Only the Accuracy attribute is used for compound numerics. The other numeric-specific attributes are not structured to handle compounds. - -#### Accuracy -The Accuracy attribute gives the maximum deviation as an absolute value of the reported measurement from the actual measurement *over the entire range of the measurement*. The reported accuracy is, thus, static and does not vary over the range of the measurement. It shall be reported if the PHD provides it and it is not corrupted. It is reported in the same unit as those of the component. This kind of measurement may not make sense to report with some compound measurements, especially in the case of the Compound-Nu-Observed-Value as each element could have different units. - -The entries are as populated as follows: - -|Observation.component element|entry|Additional Information| -|- -|code.coding.code|67914|This is the MDC code for the Accuracy attribute| -|code.coding.system|urn:iso:std:iso:11073:10101|Indicates the MDC coding system| -|code.text|optional but|Should contain the reference id MDC_ATTR_NU_ACCUR_MSMT along with any other additional text| -|valueQuantity.value|the value|This is accuracy value| -|valueQuantity.unit|optional || -|valueQuantity.system|http://unitsofmeasure.org |Indicates the UCUM coding system| -|valueQuantity.code|shall be the UCUM code of the primary measurement|Assumes the units are the same for all components| - -### Examples: -This example shows a [blood pressure](Observation-compound-numeric-blood-pressure.html) measurement. The important item to note is that there is no value[x] element in the 'primary' measurement. The set of values describing the compound are in the value[x] elements of the Observation.component elements. - - - - - - - diff --git a/input/pagecontent/DIMtoFHIRMapping.md b/input/pagecontent/DIMtoFHIRMapping.md index 24edb40..a1a934f 100644 --- a/input/pagecontent/DIMtoFHIRMapping.md +++ b/input/pagecontent/DIMtoFHIRMapping.md @@ -5,38 +5,37 @@ Observation objects in ACOM can represent different types of measurements, inclu 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. -### The Observation Model ### +### The Observation Model The IEEE 11073-10206 model describes an Observation using a type (to indicate what the measurement is) and a value and optional attributes including timestamp, status, related observations and supplemental information. -#### Measurement Values #### +#### Measurement Values The IEEE 11073-10206 Observation Model supports the following measurement values: - - **Numeric values**: Numeric values are the familiar simple quantities such as temperature and glucose concentration that are modelled using a unit and a number. Numeric values are mapped to Observation.valueQuantity elements. + - **Numeric values**: Numeric values are the familiar simple quantities such as temperature and glucose concentration that are modelled using a unit and a number. Numeric values are mapped to `Observation.valueQuantity` elements. - **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 binary "Y" or "N" Observation.component.valueCodeableConcept 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. + - **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 binary "Y" or "N" `Observation.component.valueCodeableConcept` 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. ##### Measurement Units Only numeric and sample array values may have a unit; this also applies to Numeric and Sample Array components. In ACOM, units are expressed as IEEE 11073-10101 nomenclature codes. In FHIR, these unit nomenclature codes are mapped to UCUM codes. -When an equivalent UCUM code is known this UCUM code shall be used. To keep with the generic and future interoperability design, an implementation shall use the MDC code if it does not know what the UCUM code is for the given unit code. This situation can arise if a new PHD specialization needs to use units that are not currently defined in the existing set of unit codes. When this happens, the Quantity.system will point to the MDC system and the code will be the 32-bit unit code received from the PHD. +When an equivalent UCUM code is known this UCUM code shall be used. To keep with the generic and future interoperability design, an implementation shall use the MDC code if it does not know what the UCUM code is for the given unit code. This situation can arise if a new PHD specialization needs to use units that are not currently defined in the existing set of unit codes. When this happens, the `Quantity.system` will point to the MDC system and the code will be the 32-bit unit code received from the PHD. -#### The Observation Type #### -All Observation objects contain one attribute that specify an IEEE 11073-10101 nomenclature code expressing what the Observation is. This code is given by the Observation.Type attribute. For example, a body temperature, body mass, medication dosage, or non-invasive blood pressure. The code is mapped to the Observation.code element. In compound observations, the decoder must look at the component-type attributes as well, for example the systolic, diastolic, and MAP values of the non-invasive blood pressure. These component-type codes are mapped to Observation.component.code elements representing each component. +#### The Observation Type +All Observation objects contain one attribute that specify an IEEE 11073-10101 nomenclature code expressing what the Observation is. This code is given by the `Observation.Type` attribute. For example, a body temperature, body mass, medication dosage, or non-invasive blood pressure. The code is mapped to the `Observation.code` element. In compound observations, the decoder must look at the component-type attributes as well, for example the systolic, diastolic, and MAP values of the non-invasive blood pressure. These component-type codes are mapped to `Observation.component.code` elements representing each component. -#### The Observation Model Timestamp #### -Timestamps are somewhat complex because PHDs have different types of time clocks, may include a duration, may be out of sync when using wall-clock times, and may send no timestamp at all. The PHG is responsible for placing the measurements on a UTC synchronized timeline with local offset. That includes using the time of reception as the timestamp if the PHD sends no timestamp, mapping simple relative time 'ticks' to UTC and local offset, and correcting the wall clock timestamps reported by PHDs when they are wrong. For auditing purposes, a summary of this work by the PHG is reported in the so-called Coincident Timestamp Observation resource. In the end, the PHG maps timestamps to the Observation.effectiveDateTime if the timestamp is a point in time such as for a body temperature measurement, or the Observation.effectivePeriod if the Observation contains a measurement-duration attribute such as for a running session. A reference to the Coincident Timestamp Observation, if needed, is placed in an Observation.extension.valueReference element in the [Coincident TimeStamp Reference extension](StructureDefinition-CoincidentTimeStampReference.html). +#### The Observation Model Timestamp +Timestamps are somewhat complex because PHDs have different types of time clocks, may include a duration, may be out of sync when using wall-clock times, and may send no timestamp at all. The PHG is responsible for placing the measurements on a UTC synchronized timeline with local offset. That includes using the time of reception as the timestamp if the PHD sends no timestamp, mapping simple relative time to UTC and local offset, and correcting the wall clock timestamps reported by PHDs when they are wrong. For auditing purposes, a summary of this work by the PHG is reported in the so-called Coincident Timestamp Observation resource. In the end, the PHG maps timestamps to the `Observation.effectiveDateTime` if the timestamp is a point in time such as for a body temperature measurement, or the `Observation.effectivePeriod` if the Observation contains a measurement-duration attribute such as for a running session. A reference to the Coincident Timestamp Observation, if needed, is placed in an `Observation.extension.valueReference` element in the [Coincident TimeStamp Reference extension](StructureDefinition-CoincidentTimeStampReference.html). -#### further Observation attributes #### -To be updated: -An Observation Object contains a set of optional attributes that provide additional information about the measurement. The Supplemental-Types and Accuracy are examples of such attributes. When these attributes occur, they are mapped to component elements in the FHIR Observation resource. The component.code is given by the 11073-10101 nomenclature code of the respective attribute. The component.value[x] is given by the attribute value(s). In the case of the Accuracy, the value[x] is a valueQuantity, and in the case of the Supplemental-Types, the value[x] is a valueCodeableConcept. Since the Supplemental-Types is actually a list of codes, one may need several component elements. +#### Further Observation attributes +An Observation may contain optional attributes that provide additional information about the measurement. The Supplemental-Types and Accuracy are examples of such attributes. When these attributes occur, they are mapped to component elements or extensions in the FHIR Observation resource. -The examples below show the most common basic measurement types where the PHD provides one of the wall-clock type timestamps. +The tables below show common measurement types and their mappings to FHIR Observation elements. <style>table, th, td { border: 1px solid black; @@ -47,69 +46,59 @@ padding: 6px;}</style> The simplest example of a mapping of a Numeric Metric object to a FHIR Observation resource is as follows -|IEEE Attribute|Meaning|Observation element| -|- -|Type|Tells what the measurement is as an IEEE 11073-10101 code|code| -|Absolute-Time-Stamp<br/>Base-Offset-Time-Stamp|Gives the time of the measurement|effectiveDateTime| -|Simple/Basic-Nu-Observed-Value|Gives the value of the measurement|valueQuantity.value| -|Unit-Code|Gives the units of the measurement as an IEEE 11073-10101 code. Shall be translated to the equivalent UCUM code and system when available|valueQuantity.code| +|ACOM Numeric Observation Attribute|Meaning|FHIR Observation element| +|-|---|---| +|Type|Tells what the measurement is as an IEEE 11073-10101 code|`code`| +|Time-stamp|Gives the time of the measurement|`effectiveDateTime`| +|Value|Gives the value of the measurement|`valueQuantity.value`| +|Unit-Code|Gives the units of the measurement as an IEEE 11073-10101 code. Shall be translated to the equivalent UCUM code and system when available.|`valueQuantity.code`| This mapping applies to several simple types of PHD measurements that are scalars, for example body temperature, body mass, body height, glucose concentration, among many others. This Implementation Guide specifies a structure definition profile that applies to all scalar Numeric Metric measurements. Scalar numeric measurements are the most common type of PHD measurement. -### Compound Numeric Metric Object Mapping Example - -The simplest example of a mapping of a Compound Numeric Metric object whose value has *N* components to a FHIR Observation resource is as follows: +### Compound (Numeric) Observation Mapping Example -|IEEE Attribute|Meaning|Observation element| -|- -|Type|Tells what the 'overall' measurement is as an IEEE 11073-10101 code|code| -|Absolute-Time-Stamp<br/>Base-Offset-Time-Stamp|Gives the time of the measurement|effectiveDateTime| -|Metric-Id-List.*entryN*|Gives the code of *N*th component of the measurement|component*N*.code| -|Compound Simple/Basic-Nu-Observed-Value.*valueN*|Gives the *N*th component of the measurement|component*N*.valueQuantity.value| -|Unit-Code|Gives the units of the *N*th component of the measurement as an IEEE 11073-10101 code. Shall be translated to the equivalent UCUM code and system when available|component*N*.valueQuantity.code| +The table below illustrates the mapping of a Compound Observation with *N* numeric components to a FHIR Observation resource: -This mapping applies to simple types of PHD measurements that are represented by vectors, for example, the blood pressure and the user feedback. The Type attribute indicates what the overall measurement is, and the Metric-Id-List attribute indicates what each component of the overall measurement is. In the blood pressure case, the Type states that this is a non-invasive blood pressure and the Metric-Id-List attribute identifies the systolic, diastolic, and MAP components. This implementation guide specifies a structure definition profile that applies to all compound Numeric Metric measurements. +|ACOM Observation Attribute|Meaning|FHIR Observation element| +|---|----|---| +|Type|Tells what the 'overall' measurement is as an IEEE 11073-10101 code|`code`| +|Time-stamp|Gives the time of the measurement|`effectiveDateTime`| +|components[N].component-type|Gives the code of *N*th component of the measurement|`component[N].code`| +|components[N].value|Gives value of the *N*th component of the measurement|`component[N].valueQuantity.value`| +|components[N].unit|Gives the units of the *N*th component of the measurement as an IEEE 11073-10101 code. Shall be translated to the equivalent UCUM code and system when available.|`component[N].valueQuantity.code`| -Outside of the blood pressure monitor, compound numeric measurements are relatively uncommon in PHDs. +This mapping applies to simple types of PHD measurements that are represented by vectors, for example, the blood pressure and the user feedback. The Type attribute indicates what the overall measurement is, and the components[].component-type indicates what each component of the overall measurement is. In the blood pressure case, the Type states that this is a non-invasive blood pressure and the component-type attribute identifies the systolic, diastolic, and MAP components. This implementation guide specifies a structure definition profile that applies to all Compound Observations. A dedicated profile for Compound Numeric Observations is present for backwards compatibility. -### Enumeration Coded Value Metric Object Mapping Example -The simplest example of a mapping of Enumeration Metric object, where the enumerated measurement is a code, to a FHIR Observation resource is as follows: +### Discrete Observation Mapping Example +The simplest example of a mapping of a discrete observation, where the measurement is a code, to a FHIR Observation resource is as follows: |IEEE Attribute|Meaning|Observation element| -|- -|Type|Tells what the measurement is as an IEEE 11073-10101 code|code| -|Absolute-Time-Stamp<br/>Base-Offset-Time-Stamp|Gives the time of the measurement|effectiveDateTime| -|Enum-Observed-Value-Simple-OID|Gives the value of the measurement as IEEE 11073-10101 code|valueCodeableConcept| - -This mapping applies to simple types of PHD measurements whose value is given by a finite list of codes, for example the pulsatile characteristics measurement of a pulse oximeter or the meal context associated with a glucose measurement. In the pulse oximter case there are three codes defined that can be reported; trigger on a beat, trigger on a maximum inrush, and no pulsatile event occurred. The latter is only reported by the device in special conditions and is usually not reported. This implementation guide specifies a structure definition profile that applies to all coded Metric measurements. +|-|----|---| +|Type|Tells what the measurement is as an IEEE 11073-10101 code|`code`| +|Time-stamp|Gives the time of the measurement|`effectiveDateTime`| +|value|Gives the value of the measurement as IEEE 11073-10101 code|`valueCodeableConcept`| -### Enumeration BITs Value Metric Object Mapping Example -The ASN.1 BITs measurement is the most difficult measurement class to map because HL7 does not support this measurement type. An ASN.1 BITs value is a 16 or 32-bit integer where each bit can mean something. The bit is either set (value = 1) or cleared (value = 0). This type of measurement is typically used to report events, statuses, or conditions when more than one of these situations can happen at the same time. They are classed as either events or states. To map this measurement to FHIR the BITs integer needs to be converted to codes. This IG contains a code system for this purpose allowing one to map a BITs value to a set of valueCodeableConcepts. For details about the code system and links to the code system itself see [ASN1 To HL7 CodeSystem](CodeSystem-ASN1ToHL7.html). The code system has a code for each possible setting, so a 16/32-bit ASN.1 BITs value can result in up to 16/32 codes. Since a BITs value can contain multiple settings, each setting is mapped to an Observation.component. +This mapping applies to simple types of PHD measurements whose value is given by a finite list of codes, for example the pulsatile characteristics measurement of a pulse oximeter or the meal context associated with a glucose measurement. In the pulse oximeter case there are three codes defined that can be reported; trigger on a beat, trigger on a maximum inrush, and no pulsatile event occurred. The latter is only reported by the device in special conditions and is usually not reported. This implementation guide specifies a structure definition profile that applies to all discrete observation that report a single code. -In the latest version of IEEE 11073-20601, two sets of support attributes for an ASN1 BITs measurements have been added. The Capability-Mask-Simple/Basic attribute indicates whether a given bit is supported (set) or not (cleared). The State-Flag-Simple/Basic attribute indicates whether a given bit is an event (cleared) or state (set). Unsupported bits do not need to be reported and cleared event bits do not need to be reported. Both set and cleared state bits need to be reported. Undefined bits are never reported (what bits are defined is given in the respective specialization documents). - -Since the earlier versions of the 20601 standard do not provide state/event information, the [ASN1 To HL7 CodeSystem](CodeSystem-ASN1ToHL7.html) does. There is no way to determine if a given device supports a defined bit setting so one has to assume that all defined settings are supported. Since most BITs measurements are events, the lack of support information tends not to be a problem. +### Multiple Boolean Observation Mapping Example +The Multiple Boolean Observation or bit string Observation is the most difficult measurement class to map because HL7 does not support this measurement type. The reported value is a bit string where each bit can mean something. This type of measurement is typically used to report events, statuses, or conditions when more than one of these situations can happen at the same time. They are classed as either events or states. To map this measurement to FHIR the BITs integer needs to be converted to codes. This IG contains a code system for this purpose allowing one to map a BITs value to a set of valueCodeableConcepts. For details about the code system and links to the code system itself see [ASN1 To HL7 CodeSystem](CodeSystem-ASN1ToHL7.html). The code system has a code and a definition per bit. Each bit is mapped to an `Observation.component` with one of these codes. The simplest example of a mapping of an ASN1 BITs enumeration object to a FHIR Observation resource is as follows: -|IEEE Attribute|Meaning|Observation element| -|- -|Type|Tells what the measurement is as an IEEE 11073-10101 code|code| -|Absolute-Time-Stamp<br/>Base-Offset-Time-Stamp|Gives the time of the measurement|effectiveDateTime| -|ASN1 Code for BIT *N*|Gives the code of *N*th BIT setting|component*M*.code| -|Enum-Observed-Value-Simple/Basic-Bit-Str.*BitN*|Gives the *N*th bit setting as binary yes/no|component*M*.valueCodeableConcept (Y/N)| +|ACOM Multiple Boolean Observation Attribute|Meaning|Observation element| +|---|----|---| +|Type|Tells what the measurement is as an IEEE 11073-10101 code|`code`| +|Time-stamp|Gives the time of the measurement|`effectiveDateTime`| +|ASN1 Code for bit N|Gives the code of Nth bit|`component[M].code`| +|value[N]|Gives the *N*th bit setting as Boolean|`component[M].valueBoolean`| -*M* (the number of the component) is different from *N* (the bit-position) because cleared event bits do not need to be reported. What is not shown in the table is that the ASN1 Code entered in the component*M*.code element can be generated from data sent by the PHD. The ASN1 code is generated by converting the 32-bit code from the Type attribute to a string, concatenating a dot (.) followed by the Mder bit position *N*. A reader will still need to refer to the ASN1 code dictionary to interpret the meaning. +*M* (the number of the component) may be different from *N* (the bit-position) because cleared event bits for events do not need to be reported. -This implementation guide specifies a structure definition profile that applies to all ASN1 Bits Metric measurements. +This implementation guide specifies a structure definition profile that applies to all Multiple Boolean Observation measurements. -### PhdDeviceMetric +### List of supported Observation Types The IEEE 11073-10206 ACOM specification and the Bluetooth SIG GHS specifications require a compliant device to publish the list of supported observation types. This list of observation types can be mapped to a set of [PhdDeviceMetric resources](StructureDefinition-PhdDeviceMetric.html). The GHS specifications also support an optional Observation Schedule descriptor. The information in this descriptor can be mapped to the DeviceMetric.measurementPeriod. -### The Devil is in the Details -Unfortunately, the Metric object to Observation resource mapping is not always a simple one-to-one relation between IEEE 11073-20601 attributes and Observation elements as shown in the tables above. For example, the code that ends up in the Observation.code element does not always come from the Type attribute. The PHD decoder (the endpoint that receives and decodes IEEE 20601 data) will, in general, need to look at other attributes, should they be sent, to get the final code to enter in the Observation.code element. The same goes for the unit code. The Unit-code attribute can be overridden if certain other attributes exist. - -However, this complexity is of no concern to the *consumer* or reader of the FHIR resources, only to the PHD decoder and creator of the FHIR resources, such as the a PHG that uploads PHD data according to this IG. diff --git a/input/pagecontent/DIMtoFHIRMappingDetails.md b/input/pagecontent/DIMtoFHIRMappingDetails.md index 46033f9..a5d550f 100644 --- a/input/pagecontent/DIMtoFHIRMappingDetails.md +++ b/input/pagecontent/DIMtoFHIRMappingDetails.md @@ -8,8 +8,7 @@ In this section the details of the mapping of the IEEE 11073-20601 Metric object - [Obtaining the Observation.code]({{ output }}ObtainObservationCode.html) - [Obtaining the Unit code]({{ output }}ObtainUnitCode.html) - [ASN1 BITS Code System]({{ output }}CodeSystem-ASN1ToHL7.html) - - [The Observation Identifier]({{ output }}ObservationIdentifier.html) - - [Generating the Reported Timestamp Observation Identifier]({{ output }}GeneratingtheReportedTimeStampIdentifier.html) + - [Generating the Timestamp part of the Observation Identifier]({{ output }}GeneratingtheTimeStampPartIdentifier.html) \ No newline at end of file diff --git a/input/pagecontent/GeneratingtheReportedTimeStampIdentifier.md b/input/pagecontent/GeneratingtheTimeStampPartIdentifier.md similarity index 67% rename from input/pagecontent/GeneratingtheReportedTimeStampIdentifier.md rename to input/pagecontent/GeneratingtheTimeStampPartIdentifier.md index f1ecbf5..9caf388 100644 --- a/input/pagecontent/GeneratingtheReportedTimeStampIdentifier.md +++ b/input/pagecontent/GeneratingtheTimeStampPartIdentifier.md @@ -1,6 +1,6 @@ -Note that this timestamp identifier is part of the Observation.identifier whose sole purpose is to perform a conditional create transaction. The identifier is not to be interpreted by a consumer of the resource and it should not be used for informational content. +Note that this timestamp identifier is part of the `Observation.identifier` whose sole purpose is to perform a conditional create transaction. The identifier is not to be interpreted by a consumer of the resource and it should not be used for informational content. -This algorithm shows how a gateway generates the timestamp as reported by the PHD for use in the Observation.identifier element. The Observation.identifier element is used in the PHD profiles to perform conditional creates and thus eliminate data duplication. +This algorithm shows how a gateway generates the timestamp as reported by the PHD for use in the `Observation.identifier` element. The `Observation.identifier` element is used in the PHD profiles to perform conditional creates and thus eliminate data duplication. - If the PHD timestamp reports a tick counter the reported value will be encoded as the number of seconds it represents according to its resolution. - For example, when a Bluetooth GHS sensor reports a tick counter of 12345678 with a millisecond resolution this will be encoded as "12345.678". @@ -11,6 +11,6 @@ This algorithm shows how a gateway generates the timestamp as reported by the PH - If the PHD timestamp reports a TZ/DST offset the reported value will be appended as a decimal value, including a + or - sign. - For example, when a Bluetooth GHS timestamp reports an offset of +4 (1 hour) this will be appended as "+4". Combined with the previous examples, this becomes "690897360.567+4" -- If the PHD Observation also includes a Measurement-duration attribute this will be appended to the endcoded timestamp as a ".." followed by the duration encoded according to the timestamp resolution. +- If the PHD Observation also includes a Measurement-duration attribute this will be appended to the encoded timestamp as a ".." followed by the duration encoded according to the timestamp resolution. - For example a duration of 1 second with a millisecond resolution will be appended as "..1.000". Combined with the previous example this becomes "690897360.567+4..1.000" diff --git a/input/pagecontent/ObservationIdentifier.md b/input/pagecontent/ObservationIdentifier.md deleted file mode 100644 index 66eb95d..0000000 --- a/input/pagecontent/ObservationIdentifier.md +++ /dev/null @@ -1,7 +0,0 @@ -Some PHDs will resend old data repeatedly. To prevent excessive resource duplication on the RESTful FHIR server this IG specifies an Observation.identifier whose sole purpose is to perform a conditional create transaction. The identifier is not to be interpreted by a consumer of the resource. - -The idea is that the identifier uniquely describes the measurement such that if the same measurement were resent at a later time, the identifier would be the same. At the same time it needs to be selective enough such that no other newly taken measurement will produce the same identifier. - -In practice it is preferred that the uploader filter the data in some application dependent manner such that duplicates are not sent. Duplicates, even if armed with a conditional create transaction, waste bandwidth and conditional create operations are more demanding on the server than simple create transactions. - -The identifier is generated from a combination of the basic measurement components, such as the type, value, timestamp, units, and contributions from extra descriptors should they be present. The specifics on how to create this identifier can be found in [this section of the PhdBaseObservation profile](StructureDefinition-PhdBaseObservation.html#unique-observation-identifier---prevention-of-data-duplication). diff --git a/input/pagecontent/ObtainObservationCode.md b/input/pagecontent/ObtainObservationCode.md index 26cf8cc..74481df 100644 --- a/input/pagecontent/ObtainObservationCode.md +++ b/input/pagecontent/ObtainObservationCode.md @@ -1,18 +1,19 @@ -Every IEEE 11073-10206 ACOM Observation instance is required to have a Type attribute. The Type attribute value is an MDC term code that maps directly to the Observation.code element. -The Observation.code element is populated as follows: +Every IEEE 11073-10206 ACOM Observation instance is required to have a Type attribute. The Type attribute value is an MDC term code that maps directly to the `Observation.code` element. +The `Observation.code` element is populated as follows: * if the application wishes to transcode this MDC code into other coding systems the application is free to do so but * the MDC code shall be present in a coding element * if the code matches one of the [FHIR observation-vitalsigns codes]({{ site.data.fhir.path }}observation-vitalsigns.html), the observation-vitalsigns code shall be present in a coding element * any other coding translations desired may be placed in an additional coding element. * for the MDC code the mapping is as follows: - * Observation.code.coding.code = *value* - * Observation.code.coding.system = "urn:iso:std:iso:11073:10101" - * Observation.code.text should contain the reference identifier as part of the text. + * `Observation.code.coding.code` = *value* + * `Observation.code.coding.system` = "urn:iso:std:iso:11073:10101" + * `Observation.code.display` should contain the reference identifier + * `Observation.code.text` should contain the reference identifier as part of the text followed by a localized description of the measurement type -The requirement for the MDC textual reference identifier is not mandatory and is not used as the Observation.code.coding.code value because the reference identifier is not provided by the sensor device in the exchange protocol. Requiring the reference identifier would require that the PHG have an internal map. However, the main reason for not requiring the reference identifier is that doing so would defeat future interoperability. An older PHG would not know the reference identifier of a new specialization but it would be able to propagate the new code since that is provided by the device. +The requirement for the MDC reference identifier is not mandatory and is not used as the `Observation.code.coding.code` value because the reference identifier is not provided by the sensor device in the exchange protocol. Requiring the reference identifier would require that the PHG have an internal map. However, the main reason for not requiring the reference identifier is that doing so would defeat future interoperability. An older PHG would not know the reference identifier of a new specialization but it would be able to propagate the new code since that is provided by the device. -The MDC code entry is required, but the concept may be expressed in other coding systems as well. The choice of any additional translations is up to the application. PHGs operating in certain realms may be required to provide translations to a realm-specified coding system. For example, in the United States realm, LOINC is strongly preferred. For those implementing a PHG for operations in the US, a mapping table for MDC to LOINC can be downloaded [here](https://loinc.org/file-access/download-id/9385/). One may freely use this table as needed in an implementation license free. +The MDC code entry is required, but the concept may be expressed in additional coding systems as well. The choice of any additional codings is up to the application. PHGs operating in certain realms may be required to provide translations to a realm-specified coding system. For example, in the United States realm, LOINC is strongly preferred. For those implementing a PHG for operations in the US, a mapping table for MDC to LOINC can be downloaded [here](https://loinc.org/file-access/download-id/9385/). -The consumer of FHIR resources containing the PHD data does not need to concern itself with this complexity. All it needs to do is obtain the Observation.code.coding.code element supporting the 11073-10101 system value to get the measurement type. +The consumer of FHIR resources containing the PHD data does not need to concern itself with this complexity. All it needs to do is obtain the `Observation.code.coding.code` element supporting the 11073-10101 system value to get the measurement type. diff --git a/input/pagecontent/ProfileConsumers.md b/input/pagecontent/ProfileConsumers.md index f00b695..4b10688 100644 --- a/input/pagecontent/ProfileConsumers.md +++ b/input/pagecontent/ProfileConsumers.md @@ -113,9 +113,9 @@ PHDs can send measurements that have additional descriptive information. An exam |Type of additional information|When it can occur|FHIR data element|Description| |----|---|---|---| |supplemental type|Can occur with all measurement values|`valueCodeableConcept`| provides a further description of the measurement type. Can be multiple supplemental type component entries.| -|Accuracy|Only with Quantities|`extension.valueQuantity`| Gives the accuracy of the measurement value in the units of the measurement value| -|Measurement Confidence 95|Only with Quantities|`extension.valueRange`| Gives a range that the manufacturer is 95% confident that the actual reported measurement is within that bounds| -|Simple Alerting|Only with Quantities|`complex extension`| Gives the parameters for alerting and thresholding on a quantity.| +|Accuracy|Only with Quantities|(Accuracy) `extension.valueQuantity`| Gives the accuracy of the measurement value in the units of the measurement value| +|Measurement Confidence 95|Only with Quantities|(Confidence95) `extension.valueRange`| Gives a range that the manufacturer is 95% confident that the actual reported measurement is within that bounds| +|Simple Alerting|Only with Quantities|(SimpleAlerting) `extension.*`| Gives the parameters for alerting and thresholding on a quantity.| More details on the extensions that can be used with quantities can be found in the [PhdNumericObservation profile](StructureDefinition-PhdNumericObservation.html). @@ -274,8 +274,8 @@ Periodic measurements are reported in `Observation.valueSampledData` data elemen |`Observation.valueSampledData.scaleFactor`|Contains the scale factor in the rescaling equation| |`Observation.valueSampledData.period`|gives the time interval between samples in milliseconds| |`Observation.valueSampledData.dimensions`|Always 1 in PHD (multi-dimensional arrays are not supported)| -|`Observation.valueSampledData.upperLimit`|Upper value that the original sequence can obtain| -|`Observation.valueSampledData.lowerLimit`|Lower value that the original sequence can obtain| +|`Observation.valueSampledData.upperLimit`|Scaled upper value that the sequence can obtain| +|`Observation.valueSampledData.lowerLimit`|Scaled lower value that the sequence can obtain| To obtain the original values of the measured sequence one uses the following equation: @@ -286,7 +286,7 @@ or the familiar equation of a line y(i) = mx(i) + b -The `Observation.referenceRange` element is for convenience and is not necessary for decoding the data. It was designed for plotting as it gives the upper and lower bounds of the trace at any time (it does not mean that either value is obtained in the transmitted sequence). One can create a graph with such limits without examining the sequence. +The `upperLimit` and `lowerLimit` elements are for convenience and are not necessary for decoding the data. They can be used when plotting the data as they give the upper and lower bounds of the trace at any time. One can create a graph with these limits without examining the sequence. It is possible that the periodic measurement is a vital sign, for example, a heart rate. If it is a vital sign, the same FHIR-required LOINC code requirements apply as they do for scalar and vector measurements. @@ -489,13 +489,14 @@ An example of a time resolution property for an absolute time clock with a time } #### Time Tick Resolution for R-R Intervals -The Time Tick resolution is not used for measurement timestamps but for measuring R-R intervals (time between electrocardiogram R-wave peaks) in ECG and Heart Rate specializations. The number of ticks is reported in the `valueQuantity.value` element in Observations, not the effective[x] which is the time the measurement is taken. These special clocks typically have a resolution of 1024 Hz or better. When R-R intervals are reported, they are reported in units of these ticks, so one must know what the frequency of the clock is. The reason for this special clock is that R-R intervals have been traditionally timed using dedicated crystal oscillators. +This section is only relevant for PHDs that support the Heart Rate or ECG specializations based on IEEE 11073-20601. It is not used for measurement timestamps but for measuring R-R intervals (time between electrocardiogram R-wave peaks) in ECG and Heart Rate specializations. The time tick resolution is a high frequency clock that is used to measure the time between R-wave peaks in an ECG trace. +The number of ticks is reported in the `valueQuantity.value` element in Observations, not the effective[x] which is the time the measurement is taken. These special clocks typically have a resolution of 1024 Hz or better. When R-R intervals are reported, they are reported in units of these ticks, so one must know what the frequency of the clock is. The reason for this special clock is that R-R intervals have been traditionally timed using dedicated crystal oscillators. The time tick is given as a property and its units are Hertz. However, the R-R interval is given in the number of these ticks and many PHGs will not make the conversion as there is no UCUM code for the MDC dimension code of Ticks and therefore the units reported will be the MDC unit of ticks. Thus the reader will have to obtain the R-R interval using the R-R reported tick value and the tick frequency given in the Device property element. The property is indicated by the `Device.code` having the MDC code "68229". The value is a valueQuantity. -An example of the Tick resolution property entry is given below. +An example of the Tick resolution property entry for a 1024 Hz clock is given below. { "type": { @@ -509,38 +510,14 @@ An example of the Tick resolution property entry is given below. }, "valueQuantity": [ { - "value": 1024, + "value": 976.5625, "system": "http://unitsofmeasure.org", - "code": "s-1" // 1/seconds or Hz + "code": "us" // microseconds } ] } -#### Time Synchronization Accuracy -The time synchronization accuracy is the accumulated difference between the PHD's internal clock and external reference source since last synchronization. It is reported in units of microseconds. To date no PHD is externally time synchronized so no PHD reports this attribute value. - -The property is indicated by the `Device.code` having the MDC code "68221". The value is a valueQuantity. - -An example of the time synchronization accuracy property entry is given below. - - { - "type": { - "coding": [ - { - "system": "urn:iso:std:iso:11073:10101", - "code": "68221" - } - ], - "text": "MDC_TIME_SYNC_ACCURACY: Time synchronization accuracy" - }, - "valueQuantity": [ - { - "value": 1005, - "system": "http://unitsofmeasure.org", - "code": "us" - } - ] - } +ACOM-based ECGs do not use the time tick resolution to report R-R intervals. #### Regulation Status The Regulation status is a set of states where only one state is defined. Regulation Status is used to indicate which regulation body the PHD is regulated by. At the moment, the single defined state is assumed to be FDA. All market devices that currently report a regulated state are FDA regulated. diff --git a/input/pagecontent/TechnicalImplementationGuidance.md b/input/pagecontent/TechnicalImplementationGuidance.md index b5424cc..730d633 100644 --- a/input/pagecontent/TechnicalImplementationGuidance.md +++ b/input/pagecontent/TechnicalImplementationGuidance.md @@ -13,7 +13,6 @@ The mapping sections require knowledge of the IEEE 11073-10206 model and are int - [FHIR's Codeable Concepts](CodeableConcepts.html) - [Obtaining the Observation.code](ObtainObservationCode.html) - [Obtaining the Unit code](ObtainUnitCode.html) - - [The Observation Identifier](ObservationIdentifier.html) - - [Generating the Reported Timestamp Observation Identifier](GeneratingtheReportedTimeStampIdentifier.html) + - [Generating the Timestamp part of the Observation Identifier](GeneratingtheTimeStampPartIdentifier.html) - [Coincident Timestamp](CoincidentTimeStamp.html) - [Non-IEEE 11073-10206 PHD Devices](Non11073PHDDevices.html) From 229f4f0b3ecb63021cde62bed0d9ab4928896a6c Mon Sep 17 00:00:00 2001 From: Erik Moll <erik.moll@philips.com> Date: Sun, 20 Jul 2025 15:58:18 +0200 Subject: [PATCH 04/10] Jira tickets on structure defs --- input/fsh/StructureDefinition.PhdBaseObservation.fsh | 7 +++++++ ...eDefinition.PhdCoincidentTimeStampObservation.fsh | 12 ++++++++++++ input/fsh/StructureDefinition.PhdDevice.fsh | 5 +++++ input/fsh/StructureDefinition.PhdDeviceMetric.fsh | 2 ++ input/fsh/StructureDefinition.PhgDevice.fsh | 5 ++++- 5 files changed, 30 insertions(+), 1 deletion(-) diff --git a/input/fsh/StructureDefinition.PhdBaseObservation.fsh b/input/fsh/StructureDefinition.PhdBaseObservation.fsh index 9e0bee7..1fcc795 100644 --- a/input/fsh/StructureDefinition.PhdBaseObservation.fsh +++ b/input/fsh/StructureDefinition.PhdBaseObservation.fsh @@ -114,6 +114,13 @@ Description: "Common base profile with the elements that are common to the PHD I * dataAbsentReason ^comment = "The Measurement-Status/status flags indicating invalid, not available, or msmt ongoing will generate this element and cause the value[x] to be absent. The remaining settings of the status values are reported in the meta.security element or interpretation element. Also populated when a numeric value is in error." * dataAbsentReason.coding from http://hl7.org/fhir/ValueSet/data-absent-reason (required) +* derivedFrom ^short = "A source the measurement data is derived from." +* derivedFrom only Reference(PhdBaseObservation) + * ^definition = "Reference to another PHD Observation resource that was used to create this Observation." +* hasMember ^short = "Other PHD Observations that are part of this group observation." +* hasMember only Reference(PhdBaseObservation) + * ^definition = "Reference to other PHD Observation resources that are part of this group observation; used for training sessions and other grouped measurements." + Invariant: mdc-1 Description: "A published MDC Code is preferred but private MDC codes are allowed as well." * severity = #warning diff --git a/input/fsh/StructureDefinition.PhdCoincidentTimeStampObservation.fsh b/input/fsh/StructureDefinition.PhdCoincidentTimeStampObservation.fsh index d8ac258..a6fe20e 100644 --- a/input/fsh/StructureDefinition.PhdCoincidentTimeStampObservation.fsh +++ b/input/fsh/StructureDefinition.PhdCoincidentTimeStampObservation.fsh @@ -68,3 +68,15 @@ Description: "Observations containing a coincident timestamp." * reference 1..1 * ^short = "Reference to the PHG device responsible for the coincident timestamp measurement" * ^definition = "Reference to the PHG device responsible for the coincident timestamp measurement. This element will point to a Device resource following the Phg Device Profile." +* derivedFrom 0..0 + * ^short = "No reference to a source observation in PHD. The coincident timestamp is not derived from another observation." + * ^definition = "This element is not used in PHD as the coincident timestamp is not derived from another observation." +* hasMember 0..0 + * ^short = "No reference to a group observation in PHD. The coincident timestamp is not part of a group observation." + * ^definition = "This element is not used in PHD as the coincident timestamp is not part of a group observation." +* specimen 0..0 + * ^short = "No specimen in PHD. The coincident timestamp is not associated with a specimen." + * ^definition = "This element is not used in PHD as the coincident timestamp is not associated with a specimen." +* focus 0..0 + * ^short = "No focus in PHD. The coincident timestamp is not associated with a focus." + * ^definition = "This element is not used in PHD as the coincident timestamp is not associated with a focus." diff --git a/input/fsh/StructureDefinition.PhdDevice.fsh b/input/fsh/StructureDefinition.PhdDevice.fsh index c0b560e..75bb282 100644 --- a/input/fsh/StructureDefinition.PhdDevice.fsh +++ b/input/fsh/StructureDefinition.PhdDevice.fsh @@ -125,6 +125,11 @@ Description: "Profile for the Device Resource for a PHD" //clockTypeProperty 0..1 and //powerSourceProperty 0..1 and +* parent ..0 + * ^short = "No reference to a parent device in PHD. PHDs are not part of a device hierarchy." + + + * property[timeSyncProperty] ^short = "Time synchronization method" * ^definition = "This element represents the time synchronization method used by the PHD. It is an MDC coded value." * ^comment = "The clock set method is a required attribute in the IEEE 11073-10206 standard. It is also supported by Bluetooth Low Energy ETS and GHS specifications. Strictly speaking, the time synchronization method is not a property of the PHD but rather a property of the PHG. However, it is included here as it is a required attribute in the IEEE 11073-10206 standard and is often used by the PHG to determine how to set the time on the PHD. In most cases it reflects the time synchronization method used to set the PHG's clock and strictly speaking it should not be reported as a static device property, but as part of a coincident timestamp." diff --git a/input/fsh/StructureDefinition.PhdDeviceMetric.fsh b/input/fsh/StructureDefinition.PhdDeviceMetric.fsh index 85fa6bb..865971d 100644 --- a/input/fsh/StructureDefinition.PhdDeviceMetric.fsh +++ b/input/fsh/StructureDefinition.PhdDeviceMetric.fsh @@ -29,6 +29,8 @@ Description: "Profile for the DeviceMetric for a PHD" * ^comment = "When the category can be derived from the type of the DeviceMetric it can be filled in on creation. Otherwise it can be filled in by updating the DeviceMetric resource when the PHD generates an observation of that type. It can be set to #unspecified until known." * measurementPeriod * ^comment = "when this information is provided by a GHS device in an Observation Schedule descriptor, it should be filled in here as well." +* parent ..0 + * ^short = "No reference to a parent device in PHD. PHDs are not part of a device hierarchy." * extension contains http://hl7.org/fhir/uv/phd/StructureDefinition/Accuracy named Accuracy 0..1 * extension contains http://hl7.org/fhir/uv/phd/StructureDefinition/Confidence95 named Confidence95 0..1 * extension contains http://hl7.org/fhir/uv/phd/StructureDefinition/SimpleAlerting named SimpleAlerting 0..1 \ No newline at end of file diff --git a/input/fsh/StructureDefinition.PhgDevice.fsh b/input/fsh/StructureDefinition.PhgDevice.fsh index 35aa93c..9a48423 100644 --- a/input/fsh/StructureDefinition.PhgDevice.fsh +++ b/input/fsh/StructureDefinition.PhgDevice.fsh @@ -192,4 +192,7 @@ Description: "Profile for the Device Resource for a PHG" * system 1.. * ^definition = "Either the http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaPHDInterfaceIDs or http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaHFS or urn:iso:std:iso:11073:10101 code systems" * code 1.. - * ^definition = "One of the Continua interface certification codes" \ No newline at end of file + * ^definition = "One of the Continua interface certification codes" + +* parent ..0 + * ^short = "No reference to a parent device in PHD. PHDs/PHGs are not part of a device hierarchy." \ No newline at end of file From d3aadf445ffd4885ce1ff66f9b3be89b217e1165 Mon Sep 17 00:00:00 2001 From: Erik Moll <erik.moll@philips.com> Date: Sun, 20 Jul 2025 19:07:26 +0200 Subject: [PATCH 05/10] Updated PHG profile according to Jira tickets --- FHIR-phd.xml | 1 + input/examples/bundle-example-1.json | 64 ++++- .../phg-ecde3d4e58532d31.000000000000.json | 68 ++++- input/examples/phg-example.json | 17 +- input/fsh/StructureDefinition.PhdDevice.fsh | 71 ++--- input/fsh/StructureDefinition.PhgDevice.fsh | 255 +++++++++++------- input/fsh/ValueSet.ContinuaPHGInterfaces.fsh | 10 + 7 files changed, 326 insertions(+), 160 deletions(-) create mode 100644 input/fsh/ValueSet.ContinuaPHGInterfaces.fsh diff --git a/FHIR-phd.xml b/FHIR-phd.xml index bdcbb36..33ccb23 100644 --- a/FHIR-phd.xml +++ b/FHIR-phd.xml @@ -26,6 +26,7 @@ <artifact id="CodeSystem/ContinuaDeviceIdentifiers" key="CodeSystem-ContinuaDeviceIdentifiers" name="Continua Device Identifiers"/> <artifact id="CodeSystem/ContinuaPHDInterfaceIDs" key="CodeSystem-ContinuaPHDInterfaceIDs" name="Continua Device Interface Identifiers"/> <artifact id="ValueSet/ContinuaPHDInterfaces" key="ValueSet-ContinuaPHDInterfaces" name="Continua Device Interfaces ValueSet"/> +<artifact id="ValueSet/ContinuaPHGInterfaces" key="ValueSet-ContinuaPHGInterfaces" name="Continua Device Interfaces ValueSet"/> <artifact id="CodeSystem/ContinuaHFS" key="CodeSystem-ContinuaHFS" name="Continua Health and Fitness Service Interfaces"/> <artifact deprecated="true" id="CodeSystem/ContinuaPHD" key="CodeSystem-ContinuaPHD" name="ContinuaPHD"/> <artifact deprecated="true" key="Device" name="Device"/> diff --git a/input/examples/bundle-example-1.json b/input/examples/bundle-example-1.json index 768de68..7fc6b55 100644 --- a/input/examples/bundle-example-1.json +++ b/input/examples/bundle-example-1.json @@ -152,7 +152,21 @@ "display": "observation-upload-soap" } ] - }, + } + ] + }, + { + "type": { + "coding": [ + { + "system": "urn:iso:std:iso:11073:10101", + "code": "532355", + "display": "MDC_REG_CERT_DATA_CONTINUA_AHD_CERT_LIST" + } + ], + "text": "Each element of the certified interfaces list as a separate property" + }, + "valueCode": [ { "coding": [ { @@ -161,7 +175,21 @@ "display": "observation-upload-hdata" } ] - }, + } + ] + }, + { + "type": { + "coding": [ + { + "system": "urn:iso:std:iso:11073:10101", + "code": "532355", + "display": "MDC_REG_CERT_DATA_CONTINUA_AHD_CERT_LIST" + } + ], + "text": "Each element of the certified interfaces list as a separate property" + }, + "valueCode": [ { "coding": [ { @@ -170,7 +198,21 @@ "display": "observation-upload-fhir" } ] - }, + } + ] + }, + { + "type": { + "coding": [ + { + "system": "urn:iso:std:iso:11073:10101", + "code": "532355", + "display": "MDC_REG_CERT_DATA_CONTINUA_AHD_CERT_LIST" + } + ], + "text": "Each element of the certified interfaces list as a separate property" + }, + "valueCode": [ { "coding": [ { @@ -179,7 +221,21 @@ "display": "capabilities" } ] - }, + } + ] + }, + { + "type": { + "coding": [ + { + "system": "urn:iso:std:iso:11073:10101", + "code": "532355", + "display": "MDC_REG_CERT_DATA_CONTINUA_AHD_CERT_LIST" + } + ], + "text": "Each element of the certified interfaces list as a separate property" + }, + "valueCode": [ { "coding": [ { diff --git a/input/examples/phg-ecde3d4e58532d31.000000000000.json b/input/examples/phg-ecde3d4e58532d31.000000000000.json index fd88ac3..67b81db 100644 --- a/input/examples/phg-ecde3d4e58532d31.000000000000.json +++ b/input/examples/phg-ecde3d4e58532d31.000000000000.json @@ -150,7 +150,22 @@ "code": "0" } ] - }, + } + ] + }, + + { + "type": { + "coding": [ + { + "system": "urn:iso:std:iso:11073:10101", + "code": "532355", + "display": "MDC_REG_CERT_DATA_CONTINUA_AHD_CERT_LIST" + } + ], + "text": "Certified Upload classes" + }, + "valueCode": [ { "coding": [ { @@ -158,7 +173,22 @@ "code": "3" } ] - }, + } + ] + }, + + { + "type": { + "coding": [ + { + "system": "urn:iso:std:iso:11073:10101", + "code": "532355", + "display": "MDC_REG_CERT_DATA_CONTINUA_AHD_CERT_LIST" + } + ], + "text": "Certified Upload classes" + }, + "valueCode": [ { "coding": [ { @@ -166,7 +196,21 @@ "code": "7" } ] - }, + } + ] + }, + { + "type": { + "coding": [ + { + "system": "urn:iso:std:iso:11073:10101", + "code": "532355", + "display": "MDC_REG_CERT_DATA_CONTINUA_AHD_CERT_LIST" + } + ], + "text": "Certified Upload classes" + }, + "valueCode": [ { "coding": [ { @@ -174,7 +218,21 @@ "code": "2" } ] - }, + } + ] + }, + { + "type": { + "coding": [ + { + "system": "urn:iso:std:iso:11073:10101", + "code": "532355", + "display": "MDC_REG_CERT_DATA_CONTINUA_AHD_CERT_LIST" + } + ], + "text": "Certified Upload classes" + }, + "valueCode": [ { "coding": [ { @@ -185,6 +243,8 @@ } ] }, + + { "type": { "coding": [ diff --git a/input/examples/phg-example.json b/input/examples/phg-example.json index 824f9ef..9c2f008 100644 --- a/input/examples/phg-example.json +++ b/input/examples/phg-example.json @@ -140,7 +140,21 @@ "display": "capabilities" } ] - }, + } + ] + }, + { + "type": { + "coding": [ + { + "system": "urn:iso:std:iso:11073:10101", + "code": "532355", + "display": "MDC_REG_CERT_DATA_CONTINUA_AHD_CERT_LIST" + } + ], + "text": "Certified Upload classes" + }, + "valueCode": [ { "coding": [ { @@ -152,6 +166,7 @@ } ] }, + { "type": { "coding": [ diff --git a/input/fsh/StructureDefinition.PhdDevice.fsh b/input/fsh/StructureDefinition.PhdDevice.fsh index 75bb282..dcac569 100644 --- a/input/fsh/StructureDefinition.PhdDevice.fsh +++ b/input/fsh/StructureDefinition.PhdDevice.fsh @@ -112,6 +112,9 @@ Description: "Profile for the Device Resource for a PHD" * type from MDCDeviceVersionTypes (required) * value ^short = "The version" * component ..0 +* parent ..0 + * ^short = "No reference to a parent device in PHD. PHDs are not part of a device hierarchy." + * property ^slicing.discriminator[0].type = #value // * ^slicing.discriminator[=].path = "type.coding.code" * ^slicing.discriminator[=].path = "type" @@ -121,15 +124,11 @@ Description: "Profile for the Device Resource for a PHD" continuaCertProperty 0..* and clockBitProperty 0..* and isRegulatedProperty 0..1 and - clockResolutionProperty 0..1 //and + clockResolutionProperty 0..1 and + timeSyncAccuracyProperty 0..1 // and //clockTypeProperty 0..1 and //powerSourceProperty 0..1 and -* parent ..0 - * ^short = "No reference to a parent device in PHD. PHDs are not part of a device hierarchy." - - - * property[timeSyncProperty] ^short = "Time synchronization method" * ^definition = "This element represents the time synchronization method used by the PHD. It is an MDC coded value." * ^comment = "The clock set method is a required attribute in the IEEE 11073-10206 standard. It is also supported by Bluetooth Low Energy ETS and GHS specifications. Strictly speaking, the time synchronization method is not a property of the PHD but rather a property of the PHG. However, it is included here as it is a required attribute in the IEEE 11073-10206 standard and is often used by the PHG to determine how to set the time on the PHD. In most cases it reflects the time synchronization method used to set the PHG's clock and strictly speaking it should not be reported as a static device property, but as part of a coincident timestamp." @@ -169,6 +168,18 @@ Description: "Profile for the Device Resource for a PHD" * code = UCUM#us * ^definition = "The UCUM code for microseconds is 'us'." +* property[timeSyncAccuracyProperty] ^short = "Time Synchronization Accuracy as reported by the PHD" + * ^definition = "The time synchronization accuracy as reported by the PHD in microseconds." + * type = Mdc#68221 // MDC_TIME_SYNC_ACCURACY + * ^short = "Tells what the time synchronization accuracy is" + * ^definition = "The time synchronization accuracy of the clock as reported by the PHD." + * valueQuantity 1..1 + * ^definition = "The value. All the time fields are scaled to microseconds" + * system 1.. + * system = "http://unitsofmeasure.org" (exactly) + * code = UCUM#us + * ^definition = "The UCUM code for microseconds is 'us'." + * property[isRegulatedProperty] ^short = "Regulatory status of the PHD" * ^definition = "This element represents the regulatory status of the PHD." * type = ASN1ToHL7#532354.0 @@ -182,54 +193,6 @@ Description: "Profile for the Device Resource for a PHD" * code 1.. * ^definition = "If bit is set, the device is not regulated. If cleared, the device is regulated." -// * property[quantitiesProperty] ^short = "The device properties represented by quantities such as clock resolution" -// * ^definition = "This element represents all those time properties that are a quantity such as the various clock resolutions and synchronization accuracy." -// * ^comment = "If the PHD reports that one of these given properties are unknown, this element shall not be populated for that property." -// * type from $Quantity11073MDC (required) -// * ^short = "The type of time quantity" -// * coding ^slicing.discriminator[0].type = #value -// * ^slicing.discriminator[=].path = "system" -// * ^slicing.rules = #open -// * coding contains MDCType 1..1 -// * coding[MDCType] ^short = "The 11073-10101 MDC code for the type" -// * system 1.. -// * system = "urn:iso:std:iso:11073:10101" (exactly) -// * code 1.. -// * ^definition = "The MDC code representing the property" -// * ^comment = "Currently PHDs support the reporting of the time quantities as shown in the Table. More may be added in the future\r\n\r\n Description CODE Reference Identifier\r\n ------------------------------------------------------------------------------------\r\n Absolute clock resolution 68222 MDC_TIME_RES_ABS\r\n Base-offset clock resolution 68226 MDC_TIME_RES_BO\r\n Relative time resolution 68223 MDC_TIME_RES_REL\r\n Hi Res relative time resolution 68224 MDC_TIME_RES_REL_HI_RES\r\n Time sync accuracy 68221 MDC_TIME_SYNC_ACCURACY\r\n Tick Resolution 68229 MDC_ATTR_TICK_RES\r\n" -// * text ^definition = "It is recommended to display at least the MDC reference identifier for the MDC code" -// * valueQuantity 1..1 -// * ^definition = "The value. All the time fields are scaled to microseconds" -// * system 1.. -// * system = "http://unitsofmeasure.org" (exactly) -// * ^definition = "The unit code shall use the UCUM system" -// * code 1.. -// * code = #us (exactly) -// * ^definition = "The UCUM code (for microseconds it is 'us')" -// * valueCode ..0 - - -// * property[codedListProperties] ^short = "The device properties represented by a list of codes such as the list of certified PHD or H-FS interfaces" -// * ^definition = "This element represents all those properties that are a list of codes. At the moment there is only certified PHD interfaces." -// * ^comment = "Continua certified PHDs are required to have these entries." -// * type from $CodeableConcept11073MDC (required) -// * ^short = "What the coded list is" -// * coding 1.. -// * ^short = "Required MDC code system entry" -// * system 1.. -// * system = "urn:iso:std:iso:11073:10101" (exactly) -// * code 1.. -// * ^definition = "The MDC code representing the property" -// * ^comment = "Currently PHDs support the reporting of one of the coded lists as shown in the Table. More may be added in the future\r\n\r\n Description CODE Reference Identifier Code System\r\n -----------------------------------------------------------------------------------------------------------------------------------\r\n Time synchronization 68220 MDC_TIME_SYNC_PROTOCOL\r Certified PHD interfaces 532353 MDC_REG_CERT_DATA_CONTINUA_CERT_DEV_LIST http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaPHDInterfaceIDs\r\n" -// * text ^definition = "It is recommended to display at least the MDC reference identifier for the code" -// * valueQuantity ..0 -// * valueCode 1.. -// * ^short = "There shall be one valueCode entry for every item supported by the PHG in the list" -// * coding 1.. -// * system 1.. -// * ^definition = "Either the http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaPHDInterfaceIDs or urn:iso:std:iso:11073:10101 code systems" -// * code 1.. -// * ^definition = "One of the Continua interface certification codes" Mapping: IEEE-11073-10206-PhdDevice Id: IEEE-11073-10206-PhdDevice diff --git a/input/fsh/StructureDefinition.PhgDevice.fsh b/input/fsh/StructureDefinition.PhgDevice.fsh index 9a48423..8342234 100644 --- a/input/fsh/StructureDefinition.PhgDevice.fsh +++ b/input/fsh/StructureDefinition.PhgDevice.fsh @@ -12,15 +12,15 @@ Description: "Profile for the Device Resource for a PHG" * ^date = "2017-07-07T11:39:51.3383228-04:00" * ^purpose = "This resource describes the primary features of the Personal Health Gateway (PHG). A PHG does not have any IEEE 11073-10206 Objects or attributes though it is required to have a system identifier. However, for the purposes of reporting the information about the PHG entity, it is treated as if it can provide system information, clock and power source information. For compliance with this IG, the quantities that are required to be reported are the system identifier, the time synchronization method, the manufacturer and model number (of the software, not necessarily the hardware on which the application resides), and the PCHA certified interfaces." * . ^definition = "The characteristics, operational status and capabilities of the PHG." +* identifier 1.. * identifier ^slicing.discriminator[0].type = #value - * ^slicing.discriminator[=].path = "type.coding.system" - * ^slicing.discriminator[+].type = #value - * ^slicing.discriminator[=].path = "type.coding.code" + * ^slicing.discriminator[=].path = "type" * ^slicing.rules = #open * ^short = "Information that uniquely describes the personal health device" - * ^definition = "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." + * ^definition = "An 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." * ^alias = "11073-10206 System id, transport address, etc." -* identifier 1.. +* identifier.type from http://hl7.org/fhir/uv/phd/ValueSet/MDCDeviceIdentifierTypes (extensible) + * ^short = "The type of identifier" * identifier contains systemIdIdentifier 0..1 and btmacAddressIdentifier 0..1 and @@ -29,17 +29,8 @@ Description: "Profile for the Device Resource for a PHG" * ^definition = "This entry contains the IEEE EUI-64." * ^alias = "11073-10206 System id" * type 1.. - * coding ^slicing.discriminator[0].type = #value - * ^slicing.discriminator[=].path = "system" - * ^slicing.discriminator[+].type = #value - * ^slicing.discriminator[=].path = "code" - * ^slicing.rules = #open - * coding contains SYSID 1..1 - * coding[SYSID] ^short = "IEEE 11073-10206 System Id code system" - * ^definition = "The IEEE 11073-10206 System Id code system coding" - * system 1.. - * system = "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers" (exactly) - * code = #SYSID (exactly) + * type = http://hl7.org/fhir/uv/phd/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) * ^short = "EUI-64 system identifier" @@ -52,16 +43,8 @@ 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.. - * coding ^slicing.discriminator[0].type = #value - * ^slicing.discriminator[=].path = "system" - * ^slicing.discriminator[+].type = #value - * ^slicing.discriminator[=].path = "code" - * ^slicing.rules = #open - * coding contains BTMAC 1..1 - * coding[BTMAC] ^short = "Bluetooth MAC address code system" - * ^definition = "The Bluetooth Mac address code system coding" - * system = "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers" (exactly) - * code = #BTMAC (exactly) + * type = http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers#BTMAC + * ^short = "Required Bluetooth MAC address code system coding" * system 1.. * system = "http://hl7.org/fhir/sid/eui-48/bluetooth" (exactly) * value 1.. @@ -71,16 +54,8 @@ Description: "Profile for the Device Resource for a PHG" * ^definition = "This entry contains the MAC transport address." * ^alias = "MAC Transport address" * type 1.. - * coding ^slicing.discriminator[0].type = #value - * ^slicing.discriminator[=].path = "system" - * ^slicing.discriminator[+].type = #value - * ^slicing.discriminator[=].path = "code" - * ^slicing.rules = #open - * coding contains ETHMAC 1..1 - * coding[ETHMAC] ^short = "Ethernet MAC address code system" - * ^definition = "The Ethernet MAC address code system coding" - * system = "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers" (exactly) - * code = #ETHMAC (exactly) + * type = http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers#ETHMAC + * ^short = "Required Ethernet MAC address code system coding" * system 1.. * system = "http://hl7.org/fhir/sid/eui-48/ethernet" (exactly) * value 1.. @@ -109,7 +84,7 @@ Description: "Profile for the Device Resource for a PHG" * specialization contains MDCType 1..* * specialization[MDCType] ^short = "The specialization(s) supported by the PHG." * ^definition = "The specialization(s) supported by the PHG. This element contains an entry for each supported specialization." - * systemType ^short = "The specialization standard supported by the PHD." + * systemType ^short = "The specialization standard supported by the PHG." * coding 1.. * coding from $DeviceTypes11073MDC (required) * version ^short = "A PHG may report firmware, hardware, software, internal protocol, nomenclature and ACOM versions." @@ -122,77 +97,163 @@ Description: "Profile for the Device Resource for a PHG" * type.coding from MDCDeviceVersionTypes * value ^short = "The version" * component ..0 -* property 1.. - * ^slicing.discriminator[0].type = #value +* parent ..0 + * ^short = "No reference to a parent device in PHG. PHGs are not part of a device hierarchy." + +* property ^slicing.discriminator[0].type = #value + // * ^slicing.discriminator[=].path = "type.coding.code" * ^slicing.discriminator[=].path = "type" * ^slicing.rules = #open * property contains - bitProperties 0..* and - quantitiesProperty 0..* and - codedListProperties 0..* -* property[bitProperties] ^short = "Properties reported in BITs fields" - * ^definition = "For each bit setting reported a BITs value, a bitProperties element is used." - * ^comment = "A BITs measurement is a 16 or 32-bit ASN1 BITs value where each bit means something. " - * type from $ASN1DeviceBits (required) - * ^short = "Tells what the BITs item is" - * ^definition = "One of the capabilities reported in the Mds-Time-Info.mds-time-caps-state or Reg-Cert-Data-List.regulation-status field." - * ^comment = "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" - * coding 1..1 - * ^short = "Required ASN1 code system entry" - * system 1.. - * system = "http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7" (exactly) - * code 1.. - * ^definition = "The ASN1 code made from the code and the Mder bit position" - * ^comment = "The MDC code for the regulation status field 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. One could enter some fields of the time capabilities attribute if desired." - * text ^definition = "It is recommended to display at least the ASN1 name for the given bit meaning" + timeSyncProperty 0..1 and + continuaCertPHDProperty 0..* and + continuaCertPHGProperty 0..* and + clockBitProperty 0..* and + isRegulatedProperty 0..1 and + clockResolutionProperty 0..1 and + timeSyncAccuracyProperty 0..1 // and + //clockTypeProperty 0..1 and + //powerSourceProperty 0..1 and + +* property[timeSyncProperty] ^short = "Time synchronization method" + * ^definition = "This element represents the time synchronization method used by the PHG. It is an MDC coded value." + * ^comment = "This element reflects the time synchronization method used to set the PHG's clock." + * type = Mdc#68220 // MDC_TIME_SYNC_PROTOCOL + * valueCode ..1 + * coding 1..* + * coding from http://hl7.org/fhir/uv/phd/ValueSet/MDCTimeSyncMethods (extensible) + +* property[continuaCertPHDProperty] ^short = "Continua certified PHD interfaces (from IEEE 11073-20601)" + * ^definition = "This element represents a Continua certified PHD interface that is supported by the PHG. It is an MDC coded value." + * type = Mdc#532353 // MDC_REG_CERT_DATA_CONTINUA_CERT_DEV_LIST + * valueCode ..1 + * valueCode from http://hl7.org/fhir/uv/phd/ValueSet/ContinuaPHDInterfaces (extensible) + +* property[continuaCertPHGProperty] ^short = "Continua certified PHG interfaces" + * ^definition = "This element represents a Continua certified PHG to HFS interface that is supported by the PHG. It is an MDC coded value." + * type = Mdc#532355 // MDC_REG_CERT_DATA_CONTINUA_AHD_CERT_DEV_LIST + * valueCode ..1 + * valueCode from http://hl7.org/fhir/uv/phd/ValueSet/ContinuaPHGInterfaces (extensible) + +* property[clockBitProperty] ^short = "Boolean Properties reported by the Clock" + * ^definition = "For each Boolean clock capability reported a property element is used." + * type from ASN1ClockBits (required) + * ^short = "Tells what the clock capability item is" + * ^definition = "One of the capabilities of the clock as reportedD." * valueQuantity ..0 * valueCode 1..1 - * coding ^slicing.discriminator[0].type = #value - * ^slicing.discriminator[=].path = "system" - * ^slicing.rules = #open - * coding contains V2Binary 1..1 - * coding[V2Binary] ^short = "Required V2 Binary code system entry" + * coding // from http://terminology.hl7.org/ValueSet/v2-0136 (required) * system 1.. * system = "http://terminology.hl7.org/CodeSystem/v2-0136" (exactly) * code 1.. * ^definition = "If bit is set, code contains Y if cleared, N" -* property[quantitiesProperty] ^short = "The PHG properties represented by quantities such as time synchronization accuracy" - * ^definition = "This element represents all those time properties that are a quantity such as the time synchronization accuracy." - * ^comment = "For a PHG the synchronization accuracy should be reported if known." - * type from $Quantity11073MDC (required) - * ^short = "The type of time quantity" - * coding 1.. - * ^short = "Required MDC code system entry" - * system 1.. - * system = "urn:iso:std:iso:11073:10101" (exactly) - * code 1.. - * ^definition = "The MDC code representing the property" - * ^comment = "For PHG only the time sync accuracy is of interest.\r\n\r\n Description CODE Reference Identifier\r\n ------------------------------------------------------------------------------------\r\n Absolute clock resolution 68222 MDC_TIME_RES_ABS\r\n Base-offset clock resolution 68226 MDC_TIME_RES_BO\r\n Relative time resolution 68223 MDC_TIME_RES_REL\r\n Hi Res relative time resolution 68224 MDC_TIME_RES_REL_HI_RES\r\n Time sync accuracy 68221 MDC_TIME_SYNC_ACCURACY\r\n" - * text ^definition = "It is recommended to display at least the MDC reference identifier for the code" + +* property[clockResolutionProperty] ^short = "Clock Resolution as reported" + * ^definition = "The clock resolution in microseconds." + * type from MDCClockResolutionTypes (required) + * ^short = "Tells what the clock resolution type is" + * ^definition = "The resolution of the clock as reported." * valueQuantity 1..1 - * ^definition = "The value of the reported quantity." - * valueCode ..0 -* property[codedListProperties] ^short = "The device properties represented by a list of codes such as the list of certified PHD or H-FS interfaces" - * ^definition = "This element represents all those properties that are a list of codes. At the moment there is only certified PHD interfaces." - * ^comment = "Continua certified PHDs are required to have these entries." - * type from $CodeableConcept11073MDC (required) - * ^short = "What the coded list is" - * coding 1.. - * ^short = "Required MDC code system entry" - * system 1.. - * system = "urn:iso:std:iso:11073:10101" (exactly) - * code 1.. - * ^definition = "The MDC code representing the property" - * ^comment = "Currently PHDs support the reporting of one of the coded lists as shown in the Table. More may be added in the future\r\n\r\n Description CODE Reference Identifier Code System\r\n -----------------------------------------------------------------------------------------------------------------------------------\r\n Time synchronization 68220 MDC_TIME_SYNC_PROTOCOL\r Certified PHD interfaces 532353 MDC_REG_CERT_DATA_CONTINUA_CERT_DEV_LIST http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaPHDInterfaceIDs\r\n Certified HFS interfaces 532355 MDC_REG_CERT_DATA_CONTINUA_AHD_CERT_DEV_LIST http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaHFS\r\n" - * text ^definition = "It is recommended to display at least the MDC reference identifier for the code" + * ^definition = "The value. All the time fields are scaled to microseconds" + * system 1.. + * system = "http://unitsofmeasure.org" (exactly) + * code = UCUM#us + * ^definition = "The UCUM code for microseconds is 'us'." + +* property[timeSyncAccuracyProperty] ^short = "Time Synchronization Accuracy" + * ^definition = "The time synchronization accuracy in microseconds." + * type = Mdc#68221 // MDC_TIME_SYNC_ACCURACY + * ^short = "Tells what the time synchronization accuracy is" + * ^definition = "The time synchronization accuracy of the clock." + * valueQuantity 1..1 + * ^definition = "The value. All the time fields are scaled to microseconds" + * system 1.. + * system = "http://unitsofmeasure.org" (exactly) + * code = UCUM#us + * ^definition = "The UCUM code for microseconds is 'us'." + +* property[isRegulatedProperty] ^short = "Regulatory status of the PHG" + * ^definition = "This element represents the regulatory status of the PHG." + * type = ASN1ToHL7#532354.0 + * ^short = "Negated regulatory status of the PHG" + * ^definition = "This element represents the negated regulatory status of the PHG." * valueQuantity ..0 - * valueCode 1.. - * ^short = "There shall be one valueCode entry for every item supported by the PHG in the list" - * coding 1.. + * valueCode 1..1 + * coding // from http://terminology.hl7.org/ValueSet/v2-0136 (required) * system 1.. - * ^definition = "Either the http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaPHDInterfaceIDs or http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaHFS or urn:iso:std:iso:11073:10101 code systems" + * system = "http://terminology.hl7.org/CodeSystem/v2-0136" (exactly) * code 1.. - * ^definition = "One of the Continua interface certification codes" + * ^definition = "If bit is set, the device is not regulated. If cleared, the device is regulated." -* parent ..0 - * ^short = "No reference to a parent device in PHD. PHDs/PHGs are not part of a device hierarchy." \ No newline at end of file + +// * property 1.. +// * ^slicing.discriminator[0].type = #value +// * ^slicing.discriminator[=].path = "type" +// * ^slicing.rules = #open +// * property contains +// bitProperties 0..* and +// quantitiesProperty 0..* and +// codedListProperties 0..* +// * property[bitProperties] ^short = "Properties reported in BITs fields" +// * ^definition = "For each bit setting reported a BITs value, a bitProperties element is used." +// * ^comment = "A BITs measurement is a 16 or 32-bit ASN1 BITs value where each bit means something. " +// * type from $ASN1DeviceBits (required) +// * ^short = "Tells what the BITs item is" +// * ^definition = "One of the capabilities reported in the Mds-Time-Info.mds-time-caps-state or Reg-Cert-Data-List.regulation-status field." +// * ^comment = "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" +// * coding 1..1 +// * ^short = "Required ASN1 code system entry" +// * system 1.. +// * system = "http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7" (exactly) +// * code 1.. +// * ^definition = "The ASN1 code made from the code and the Mder bit position" +// * ^comment = "The MDC code for the regulation status field 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. One could enter some fields of the time capabilities attribute if desired." +// * text ^definition = "It is recommended to display at least the ASN1 name for the given bit meaning" +// * valueQuantity ..0 +// * valueCode 1..1 +// * coding ^slicing.discriminator[0].type = #value +// * ^slicing.discriminator[=].path = "system" +// * ^slicing.rules = #open +// * coding contains V2Binary 1..1 +// * coding[V2Binary] ^short = "Required V2 Binary code system entry" +// * system 1.. +// * system = "http://terminology.hl7.org/CodeSystem/v2-0136" (exactly) +// * code 1.. +// * ^definition = "If bit is set, code contains Y if cleared, N" +// * property[quantitiesProperty] ^short = "The PHG properties represented by quantities such as time synchronization accuracy" +// * ^definition = "This element represents all those time properties that are a quantity such as the time synchronization accuracy." +// * ^comment = "For a PHG the synchronization accuracy should be reported if known." +// * type from $Quantity11073MDC (required) +// * ^short = "The type of time quantity" +// * coding 1.. +// * ^short = "Required MDC code system entry" +// * system 1.. +// * system = "urn:iso:std:iso:11073:10101" (exactly) +// * code 1.. +// * ^definition = "The MDC code representing the property" +// * ^comment = "For PHG only the time sync accuracy is of interest.\r\n\r\n Description CODE Reference Identifier\r\n ------------------------------------------------------------------------------------\r\n Absolute clock resolution 68222 MDC_TIME_RES_ABS\r\n Base-offset clock resolution 68226 MDC_TIME_RES_BO\r\n Relative time resolution 68223 MDC_TIME_RES_REL\r\n Hi Res relative time resolution 68224 MDC_TIME_RES_REL_HI_RES\r\n Time sync accuracy 68221 MDC_TIME_SYNC_ACCURACY\r\n" +// * text ^definition = "It is recommended to display at least the MDC reference identifier for the code" +// * valueQuantity 1..1 +// * ^definition = "The value of the reported quantity." +// * valueCode ..0 +// * property[codedListProperties] ^short = "The device properties represented by a list of codes such as the list of certified PHD or H-FS interfaces" +// * ^definition = "This element represents all those properties that are a list of codes. At the moment there is only certified PHD interfaces." +// * ^comment = "Continua certified PHDs are required to have these entries." +// * type from $CodeableConcept11073MDC (required) +// * ^short = "What the coded list is" +// * coding 1.. +// * ^short = "Required MDC code system entry" +// * system 1.. +// * system = "urn:iso:std:iso:11073:10101" (exactly) +// * code 1.. +// * ^definition = "The MDC code representing the property" +// * ^comment = "Currently PHDs support the reporting of one of the coded lists as shown in the Table. More may be added in the future\r\n\r\n Description CODE Reference Identifier Code System\r\n -----------------------------------------------------------------------------------------------------------------------------------\r\n Time synchronization 68220 MDC_TIME_SYNC_PROTOCOL\r Certified PHD interfaces 532353 MDC_REG_CERT_DATA_CONTINUA_CERT_DEV_LIST http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaPHDInterfaceIDs\r\n Certified HFS interfaces 532355 MDC_REG_CERT_DATA_CONTINUA_AHD_CERT_DEV_LIST http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaHFS\r\n" +// * text ^definition = "It is recommended to display at least the MDC reference identifier for the code" +// * valueQuantity ..0 +// * valueCode 1.. +// * ^short = "There shall be one valueCode entry for every item supported by the PHG in the list" +// * coding 1.. +// * system 1.. +// * ^definition = "Either the http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaPHDInterfaceIDs or http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaHFS or urn:iso:std:iso:11073:10101 code systems" +// * code 1.. +// * ^definition = "One of the Continua interface certification codes" \ No newline at end of file diff --git a/input/fsh/ValueSet.ContinuaPHGInterfaces.fsh b/input/fsh/ValueSet.ContinuaPHGInterfaces.fsh new file mode 100644 index 0000000..eb22cb5 --- /dev/null +++ b/input/fsh/ValueSet.ContinuaPHGInterfaces.fsh @@ -0,0 +1,10 @@ +ValueSet: ContinuaPHGInterfaces +Id: ContinuaPHGInterfaces +Title: "Continua Device Interfaces ValueSet" +Description: "ValueSet containing all codes from the ContinuaHFS CodeSystem, representing Continua Health and Fitness Server (HFS) interfaces supported by a PHG." +* ^meta.profile = "http://hl7.org/fhir/StructureDefinition/shareablevalueset" +* ^url = "http://hl7.org/fhir/uv/phd/ValueSet/ContinuaPHGInterfaces" +* ^version = "current" +* ^experimental = false +* ^publisher = "Health Level Seven International (Devices Work Group)" +* ^compose.include.system = "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaHFS" \ No newline at end of file From 2b9ff68057160fdc4db44c5cc891cf39c4ec4a77 Mon Sep 17 00:00:00 2001 From: Erik Moll <erik.moll@philips.com> Date: Mon, 21 Jul 2025 00:25:39 +0200 Subject: [PATCH 06/10] further Jira tickets --- FHIR-phd.xml | 4 +- .../phd-74E8FFFEFF051C00.001C05FFE874.json | 20 +- ...StructureDefinition.PhdBaseObservation.fsh | 2 +- input/fsh/ValueSet.ContinuaPHDInterfaces.fsh | 2 +- input/fsh/ValueSet.ContinuaPHGInterfaces.fsh | 2 +- .../StructureDefinition-PhdDevice-notes.md | 63 +++-- .../StructureDefinition-PhgDevice-intro.md | 21 +- .../StructureDefinition-PhgDevice-notes.md | 220 +++--------------- .../ValueSet-DeviceTypes11073MDC-intro.md | 2 +- input/pagecontent/CodeableConcepts.md | 6 +- input/pagecontent/DefinitionMetricMsmt.md | 2 +- input/pagecontent/ObtainObservationCode.md | 2 +- input/pagecontent/ObtainUnitCode.md | 4 +- input/pagecontent/ProfileConsumers.md | 86 +------ 14 files changed, 116 insertions(+), 320 deletions(-) diff --git a/FHIR-phd.xml b/FHIR-phd.xml index 33ccb23..4031530 100644 --- a/FHIR-phd.xml +++ b/FHIR-phd.xml @@ -25,9 +25,9 @@ <artifact id="StructureDefinition/Confidence95" key="StructureDefinition-Confidence95" name="Confidence 95 range"/> <artifact id="CodeSystem/ContinuaDeviceIdentifiers" key="CodeSystem-ContinuaDeviceIdentifiers" name="Continua Device Identifiers"/> <artifact id="CodeSystem/ContinuaPHDInterfaceIDs" key="CodeSystem-ContinuaPHDInterfaceIDs" name="Continua Device Interface Identifiers"/> -<artifact id="ValueSet/ContinuaPHDInterfaces" key="ValueSet-ContinuaPHDInterfaces" name="Continua Device Interfaces ValueSet"/> -<artifact id="ValueSet/ContinuaPHGInterfaces" key="ValueSet-ContinuaPHGInterfaces" name="Continua Device Interfaces ValueSet"/> <artifact id="CodeSystem/ContinuaHFS" key="CodeSystem-ContinuaHFS" name="Continua Health and Fitness Service Interfaces"/> +<artifact id="ValueSet/ContinuaPHDInterfaces" key="ValueSet-ContinuaPHDInterfaces" name="Continua PHD-PHG Device Interfaces ValueSet"/> +<artifact id="ValueSet/ContinuaPHGInterfaces" key="ValueSet-ContinuaPHGInterfaces" name="Continua PHG-HFS Interfaces ValueSet"/> <artifact deprecated="true" id="CodeSystem/ContinuaPHD" key="CodeSystem-ContinuaPHD" name="ContinuaPHD"/> <artifact deprecated="true" key="Device" name="Device"/> <artifact deprecated="true" id="ValueSet/DeviceSystemIdIdentifier" key="ValueSet-DeviceSystemIdIdentifier" name="Device System Id Identifier"/> diff --git a/input/examples/phd-74E8FFFEFF051C00.001C05FFE874.json b/input/examples/phd-74E8FFFEFF051C00.001C05FFE874.json index c269a53..2548e7e 100644 --- a/input/examples/phd-74E8FFFEFF051C00.001C05FFE874.json +++ b/input/examples/phd-74E8FFFEFF051C00.001C05FFE874.json @@ -295,6 +295,24 @@ "text": "relative time supported" } ] - } + }, + { + "type": { + "coding": [ + { + "system": "urn:iso:std:iso:11073:10101", + "code": "68223" + } + ], + "text": "MDC_TIME_RES_REL: relative time clock resolution" + }, + "valueQuantity": [ + { + "value": 1000, + "system": "http://unitsofmeasure.org", + "code": "us" + } + ] + } ] } \ No newline at end of file diff --git a/input/fsh/StructureDefinition.PhdBaseObservation.fsh b/input/fsh/StructureDefinition.PhdBaseObservation.fsh index 1fcc795..8de39b3 100644 --- a/input/fsh/StructureDefinition.PhdBaseObservation.fsh +++ b/input/fsh/StructureDefinition.PhdBaseObservation.fsh @@ -99,7 +99,7 @@ Description: "Common base profile with the elements that are common to the PHD I * system = "urn:iso:std:iso:11073:10101" (exactly) * code 1.. * code = #68193 (exactly) - * ^definition = "68193 is the 32-bit nomenclature code indicating a 'Supplemental-Types' value" + * ^definition = "68193 is the MDC code indicating a 'Supplemental-Types' value" * display ^definition = "It is recommended to display at least the reference identifier for the Supplemental-Types which is MDC_ATTR_SUPPLEMENTAL_TYPES" // * value[x] 1.. // * valueCodeableConcept 1..1 diff --git a/input/fsh/ValueSet.ContinuaPHDInterfaces.fsh b/input/fsh/ValueSet.ContinuaPHDInterfaces.fsh index aaf3f3e..c2cde55 100644 --- a/input/fsh/ValueSet.ContinuaPHDInterfaces.fsh +++ b/input/fsh/ValueSet.ContinuaPHDInterfaces.fsh @@ -1,6 +1,6 @@ ValueSet: ContinuaPHDInterfaces Id: ContinuaPHDInterfaces -Title: "Continua Device Interfaces ValueSet" +Title: "Continua PHD-PHG Device Interfaces ValueSet" Description: "ValueSet containing all codes from the ContinuaPHDInterfaceIDs CodeSystem, representing Continua Personal Area Network (PHD) interfaces supported by a Personal Health Gateway." * ^meta.profile = "http://hl7.org/fhir/StructureDefinition/shareablevalueset" * ^url = "http://hl7.org/fhir/uv/phd/ValueSet/ContinuaPHDInterfaces" diff --git a/input/fsh/ValueSet.ContinuaPHGInterfaces.fsh b/input/fsh/ValueSet.ContinuaPHGInterfaces.fsh index eb22cb5..a15af87 100644 --- a/input/fsh/ValueSet.ContinuaPHGInterfaces.fsh +++ b/input/fsh/ValueSet.ContinuaPHGInterfaces.fsh @@ -1,6 +1,6 @@ ValueSet: ContinuaPHGInterfaces Id: ContinuaPHGInterfaces -Title: "Continua Device Interfaces ValueSet" +Title: "Continua PHG-HFS Interfaces ValueSet" Description: "ValueSet containing all codes from the ContinuaHFS CodeSystem, representing Continua Health and Fitness Server (HFS) interfaces supported by a PHG." * ^meta.profile = "http://hl7.org/fhir/StructureDefinition/shareablevalueset" * ^url = "http://hl7.org/fhir/uv/phd/ValueSet/ContinuaPHGInterfaces" diff --git a/input/intro-notes/StructureDefinition-PhdDevice-notes.md b/input/intro-notes/StructureDefinition-PhdDevice-notes.md index 4056509..a34d854 100644 --- a/input/intro-notes/StructureDefinition-PhdDevice-notes.md +++ b/input/intro-notes/StructureDefinition-PhdDevice-notes.md @@ -1,9 +1,9 @@ The section below describe the profiled elements in more detail. -### System Identifier → Device.identifier -All IEEE 11073-10206 PHDs are required to have a system identifier. This usually is an EUI-64 consisting of 8 bytes. The EUI-64 is mapped to the FHIR Device.identifier.value element as a sequence of 8 2-digit bytes as HEX separated by dashes without the '0x' prefix commonly used in programming languages. An example of such a string is FE-ED-AB-EE-DE-AD-77-C3. Though required by IEEE 11073-10206, it is not required in the Bluetooth Low Energy health device specifications. When a PHG encounters such a device it shall provide a transport address as a means of uniquely identifying the PHD. Supported transport addresses are Bluetooth and ZigBee. The Bluetooth address is an EUI-48, and the ZigBee address is an EUI-64. These will be encoded as strings just as the EUI-64. Note that USB.vid (vendor id) and USB.pid (product id) are not unique and cannot be used as system identifiers. +### System Identifier → `Device.identifier` + All IEEE 11073-10206 PHDs are required to have a system identifier. This usually is an EUI-64 consisting of 8 bytes. The EUI-64 is mapped to the FHIR `Device.identifier.value` element as a sequence of 8 2-digit bytes as HEX separated by dashes without the '0x' prefix commonly used in programming languages. An example of such a string is FE-ED-AB-EE-DE-AD-77-C3. Though required by IEEE 11073-10206, it is not required in the Bluetooth Low Energy health device specifications. When a PHG encounters such a device it shall provide a transport address as a means of uniquely identifying the PHD. Supported transport addresses are Bluetooth and ZigBee. The Bluetooth address is an EUI-48, and the ZigBee address is an EUI-64. These will be encoded as strings just as the EUI-64. Note that USB.vid (vendor id) and USB.pid (product id) are not unique and cannot be used as system identifiers. -In order to discriminate between an identifier that is a system id and that which is a transport address the identifier.type element is used. A dedicated CodeSystem [Device Identifier Codes](CodeSystem-ContinuaDeviceIdentifiers.html) has the codes one can use to populate the identifier.type.coding.code element. +In order to discriminate between an identifier that is a system id and that which is a transport address the `identifier.type` element is used. A dedicated CodeSystem [Device Identifier Codes](CodeSystem-ContinuaDeviceIdentifiers.html) has the codes one can use to populate the `identifier.type.coding.code` element. When in the future other system identifiers such as ETSI-ICCID (International Circuit Card Identifier) are used, this coding scheme will need to be extended. @@ -25,57 +25,56 @@ The URIs used for the system can be found in the [External Identifier Systems](h An example of a system identifier is: {% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON EXCEPT:identifier %} -### UDI → Device.udiCarrier -The UDI is included as an optional attribute of a PHD in the IEEE 11073-10206 ACOM standard (and the older IEEE 11073-20601 standard). It is also supported in the Bluetooth SIG Device Information Service and the GHS Profile. The UDI elements supported are issuer, jurisdiction, Device Identifier, and the Human Readable Barcode String. The udiCarrier does have elements for each of these entries. The entryType code for this sourcing of the UDI `electronic-transmission` is used as the UDI is transmitted electronically. +### UDI → `Device.udiCarrier` + The UDI is included as an optional attribute of a PHD in the IEEE 11073-10206 ACOM standard (and the older IEEE 11073-20601 standard). It is also supported in the Bluetooth SIG Device Information Service and the GHS Profile. The UDI elements supported are issuer, jurisdiction, Device Identifier, and the Human Readable Barcode String. The udiCarrier does have elements for each of these entries. The entryType code for this sourcing of the UDI `electronic-transmission` is used as the UDI is transmitted electronically. The UDI of a device consists of a Device Identifier (DI) and a Production Identifier (PI). The DI is the part of the UDI that identifies the specific model of the device. The PI is used to identify the specific instance of the device, such as its serial number or lot number. When the PI includes a serial number it identifies a specific instance of the devices of the model as specified by the DI. -### Device.type -The Device type is the same for all PHDs and it indicates that the device is a PHD. The details of what the PHD does is found in the Device.specializations element. The MDC code being used is 65573 (reference id MDC_MOC_VMS_MDS_SIMP). In IEEE 11073-10201 this code is described as indicating "a single-purpose medical device". +### `Device.type` + The Device type is the same for all PHDs and it indicates that the device is a PHD. The details of what the PHD does is found in the `Device.specialization` element. The MDC code being used is 65573 (reference id MDC_MOC_VMS_MDS_SIMP). In IEEE 11073-10201 this code is described as indicating "a single-purpose medical device". An example of a `Device.type` encoding is: {% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON EXCEPT:type %} -The display element is optional but is recommended. +The `display` element is optional but is recommended. -### System Type Spec List → Device.specialization -The System-Type-Spec-List attribute contains a list of specializations the PHD complies to. The elements in the list indicate not only what the PHD does, but that it does so in a manner specified in the specialization documents. Each element in the list contains the specialization and its version. In most cases there is just one entry in the list. - -The specialization is encoded as a 32-bit code, where the first 16 bits are the partition INFRA and the last 16 bits are the term code from System-Type-Spec-List.type. The version is encoded as a 16-bit number. The code and version are encoded in the Device.specialization element as follows: +### System Type Spec List → `Device.specialization` + The System-Type-Spec-List attribute contains a list of specializations the PHD complies to. The elements in the list indicate not only what the PHD does, but that it does so in a manner specified in the specialization documents. Each element in the list contains the specialization and its version. In most cases there is just one entry in the list. +The specialization is an MDC code for a PHD device specialization. The version is encoded as a integer number. In FHIR the code and version are encoded in the `Device.specialization` element as follows: {% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON EXCEPT:specialization %} -The display element is optional but it is highly recommended that it be included and the reference id be in the description. +The `display` element containing the reference Id is optional, but is recommended. The `text` element is optional as well and could contain a human-readable description of the specialization. The MDC_DEV_SPEC_PROFILE_GENERIC 'generic' device on the PHD side indicates that the device follows the IEEE 11073-10206 ACOM standard but not any specific specialization. On the PHG side it indicates that the PHG understands anything following the IEEE 11073-10206 standard. That would include all specializations since all specializations comply with the IEEE 11073-10206 standard. ### Manufacturer, System Model and Serial Number The ACOM Manufacturer, System-Model and Serial Number attributes contains strings. The Device resource has stand-alone primitive elements for these fields to which these attributes are mapped. -### Revision information → Device.version -The revision information provided by the PHD, such as the hardware-revision, is encoded in the Device.version element. The version information is provided as a list of versions, where each version has a type and a value. The type is encoded as an MDC code and the value is a string. The type codes are defined in the [MDC Device Version Type Codes ValueSet](ValueSet-MDCDeviceVersionTypes.html). +### Revision information → `Device.version` + The revision information provided by the PHD, such as the hardware-revision, is encoded in the `Device.version` element. The version information is provided as a list of versions, where each version has a type and a value. The type is encoded as an MDC code and the value is a string. The type codes are defined in the [MDC Device Version Type Codes ValueSet](ValueSet-MDCDeviceVersionTypes.html). ### Reg-Cert-Data-List The Reg-Cert-Data-List can be provided by PHDs based on the IEEE 11073-20601 standard. It is not supported by the IEEE 11073-10206 ACOM standard. -It contains the Continua version, list of certified PHD interfaces, and the regulation status. The Continua version is mapped to an additional Device.version element and the other two fields are mapped to a Device.property element. +It contains the Continua version, list of certified PHD interfaces, and the regulation status. The Continua version is mapped to an additional `Device.version` element and the other two fields are mapped to a `Device.property` element. -#### Reg-Cert-Data-List Certified PHD interfaces → Device.property -The Reg-Cert-Data-List attribute reports the list of Continua certified PHD (Personal Area Network) interfaces as a list interface codes. The codes obtained from the Reg-Cert-Data-List are a combination of a transport code and a device specialization code. See [the PHD Interface codes](CodeSystem-ContinuaPHDInterfaceIDs.html) for the list of possible codes. +#### Reg-Cert-Data-List Certified PHD interfaces → `Device.property` + The Reg-Cert-Data-List attribute reports the list of Continua certified PHD (Personal Area Network) interfaces as a list interface codes. The codes obtained from the Reg-Cert-Data-List are a combination of a transport code and a device specialization code. See [the PHD Interface codes](CodeSystem-ContinuaPHDInterfaceIDs.html) for the list of possible codes. -The interface codes are mapped to a list of properties where the property.valueCode element carries a single PHD interface code. The property.type element, which identifies the property, is given by the MDC code `532353`. Its reference id is `MDC_REG_CERT_DATA_CONTINUA_CERT_DEV_LIST`. +The interface codes are mapped to a list of properties where the `property.valueCode` element carries a single PHD interface code. The `property.type` element, which identifies the property, is given by the MDC code `532353`. Its reference id is `MDC_REG_CERT_DATA_CONTINUA_CERT_DEV_LIST`. #### Reg-Cert-Data-List Regulation Status -The regulation status element has MDC code `532354` and carries a 16-bit ASN1 BITs 'state' value (see [ASN1 To HL7 CodeSystem](CodeSystem-ASN1ToHL7.html)). Only bit 0 is defined. Being a state value, both set and cleared states are reported. In fact, it is the cleared state which represents that the device is regulated. The regulation status is mapped to an additional Device.property.valueCode element. +The regulation status element has MDC code `532354` and carries a 16-bit ASN1 BITs 'state' value (see [ASN1 To HL7 CodeSystem](CodeSystem-ASN1ToHL7.html)). Only bit 0 is defined. Being a state value, both set and cleared states are reported. In fact, it is the cleared state which represents that the device is regulated. The regulation status is mapped to an additional `Device.property.valueCode` element. A fragment: {% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON BASE:property.where(type.coding.code='532354') %} ### Clock information -The ACOM clock information is encoded in a set of Device.property elements. +The ACOM clock information is encoded in a set of `Device.property` elements. -#### Clock resolution → Device.property -The ACOM clock type and resolution is encoded as a Device.property element with the type code indicating the type of the clock. This is a code from [MDCClockResolutionTypes](ValueSet-MDCClockResolutionTypes.html). The value is scaled to a valueQuantity with microseconds `us` as unit. The system is `http://unitsofmeasure.org` (UCUM). +#### Clock resolution → `Device.property` + The ACOM clock type and resolution is encoded as a `Device.property` element with the type code indicating the type of the clock. This is a code from [MDCClockResolutionTypes](ValueSet-MDCClockResolutionTypes.html). The value is scaled to a valueQuantity with microseconds `us` as unit. The system is `http://unitsofmeasure.org` (UCUM). The table below shows the types of clocks that ACOM supports and the codes used to indicate them. |Clock Type|MDC Code| @@ -86,10 +85,10 @@ The table below shows the types of clocks that ACOM supports and the codes used In devices implementing the Bluetooth GHS profile specification the clock information is provided in the Elapsed Time characteristic. In other Bluetooth Low Energy devices the clock information may be inferred from the Current Time Service. -#### Time Capabilities → Device.property -ACOM supports the following Boolean time capabilities that are mapped to Boolean Device.property elements using a code from the valueSet [ASN1 Clock Bits](ValueSet-ASN1ClockBits.html). +#### Time Capabilities → `Device.property` + ACOM supports the following Boolean time capabilities that are mapped to Boolean `Device.property` elements using a code from the valueSet [ASN1 Clock Bits](ValueSet-ASN1ClockBits.html). -|ACOM time capability|Device.property.type.coding.code| +|ACOM time capability|`Device.property.type.coding.code`| |---|---| |Set Clock is supported|68219.1| |Base Offset Time is supported|68219.7| @@ -103,15 +102,15 @@ In ACOM the time synchronization used by the PHG that set the PHD's clock is pre In IEEE 11073-20601 the external time synchronization method supported by the PHD itself may be indicated in the Mds-Time-Info attribute. In this case it can be mapped to a Device property. #### Time Synchronization Accuracy -This information is not supported in ACOM. In IEEE 11073-20601 the Mds-Time-Info attribute has a field that indicates the accuracy of the time synchronization. This can be mapped to a Device.property element with code Mdc#68221 (MDC_TIME_SYNC_ACCURACY). The value is a Quantity with units of microseconds `us` and the system is `http://unitsofmeasure.org` (UCUM). +This information is not supported in ACOM. In IEEE 11073-20601 the Mds-Time-Info attribute has a field that indicates the accuracy of the time synchronization. This can be mapped to a `Device.property` element with code Mdc#68221 (MDC_TIME_SYNC_ACCURACY). The value is a Quantity with units of microseconds `us` and the system is `http://unitsofmeasure.org` (UCUM). ### Consumer of the PHD Device Profile For the Consumer of this profile the following table gives a quick guide to the main features. |item|Device resource element|value |---|---|---| -|Type of device|specialization.systemType.coding.code|MDC code for device specialization| -|Manufacturer name|manufacturer|string -|Model number|modelNumber|string -|Serial number|serialNumber|string -|System identifier|identifier.value|EUI-64 system id or unique transport address as a series of 2-digit HEX values separated by dashes| +|Type of device|`specialization.systemType.coding.code`| MDC code for device specialization| +|Manufacturer name|`manufacturer`|string +|Model number|`modelNumber`|string +|Serial number|`serialNumber`|string +|System identifier|`identifier.value`| EUI-64 system id or unique transport address as a series of 2-digit HEX values separated by dashes| diff --git a/input/intro-notes/StructureDefinition-PhgDevice-intro.md b/input/intro-notes/StructureDefinition-PhgDevice-intro.md index 8297d0b..e738e4b 100644 --- a/input/intro-notes/StructureDefinition-PhgDevice-intro.md +++ b/input/intro-notes/StructureDefinition-PhgDevice-intro.md @@ -2,29 +2,18 @@ The properties and specifications of the Personal Health Gateway (PHG) are repor PHGs may be implemented on a mobile phone, a personal computer, or in a dedicated set-top box. PHGs may be headless (provide no direct user interface). -A PHG does not have an MDS object, but for the purposes of reporting the PHG information, like its system identifier, time synchronization, and serial number, these values are treated *as if* they came from MDS-attributes in an MDS object. These 'mock' attributes and object are not required to exist on the PHG. +A PHG does not have an System-Information and Clock object, but for the purposes of reporting the PHG information, like its system identifier, time synchronization, and serial number, these values are treated *as if* they came from these objects. -Unlike the PHD where one reports the information if delivered, in the PHG case far fewer fields are required to be reported. The following table summarizes the required 'MDS' fields and their mappings: +Unlike the PHD where one reports the information if delivered, in the PHG case far fewer fields are required to be reported. The following table summarizes the required fields and their mappings: <style>table, th, td { border: 1px solid black; border-collapse:collapse; padding: 6px;}</style> -|'PHG MDS' field|Device element| -|- +|Required field|Device element| +|--|---| |System Identifier|identifier| |Time sync protocol|property| -For Continua compliance, the values in the mock Reg-Cert-Data-List shall be included: - -|'Continua PHG MDS' field|Device element| -|- -|Continua Version|version| -|Certified PHD Interfaces|property| -|Certified H&FS Interfaces|property| -|Regulation status|property| - -A transport address is not required. It is still strongly recommended that the transport address is reported as it is often beneficial to consumers. Most PHD-PHG transports provide a means of obtaining a transport address or an equivalent identifier such as a USB VID and PID. In addition, it may be beneficial to report the transport address of the H&FS interface as well, such as the MAC address. - -Similar to the PHD case, when CodeableConcept data types are used it is recommended to put the MDC reference identifier as part of the text element when the system element indicates the MDC coding system "urn.iso.std.iso:11073:10101". \ No newline at end of file +A transport address is not required. It is still strongly recommended that the transport address is reported as it is often beneficial to consumers. Most PHD-PHG transports provide a means of obtaining a transport address or an equivalent identifier such as a MAC address. In addition, it may be beneficial to report the transport address of the H&FS interface as well. diff --git a/input/intro-notes/StructureDefinition-PhgDevice-notes.md b/input/intro-notes/StructureDefinition-PhgDevice-notes.md index 6b4c6a4..575fa73 100644 --- a/input/intro-notes/StructureDefinition-PhgDevice-notes.md +++ b/input/intro-notes/StructureDefinition-PhgDevice-notes.md @@ -1,59 +1,27 @@ -### **System Identifier** -PHGs are required to have a system identifier. This identifier follows the same rules as the [PHD system identifier](StructureDefinition-PhdDevice.html#system-identifier--deviceidentifier). The system identifier is a unique identifier for the PHG and is used to identify the PHG in the FHIR server. The system identifier is represented as a Device.identifier element. +The sections below describe the profiled elements in more detail. + +#### **System Identifier** +PHGs are required to have a system identifier. This identifier follows the same rules as the [PHD system identifier](StructureDefinition-PhdDevice.html#system-identifier--deviceidentifier). The system identifier is a unique identifier for the PHG and is used to identify the PHG in the FHIR server. The system identifier is represented as a `Device.identifier` element. An example of a gateway reporting both its Bluetooth and MAC addresses is shown [here](Device-phg-ecde3d4e58532d31.000000000000.html) #### **Device type** -The PHG Device.type is given by the MDC code 531981. The reference identifier for this code is MDC_MOC_VMS_MDS_AHD. "AHD" stands for Application Hosting Device and is the name Continua gave to what is commonly known as a PHG. +The PHG `Device.type` is given by the MDC code 531981. The reference identifier for this code is `MDC_MOC_VMS_MDS_AHD`. "AHD" stands for Application Hosting Device and is the name Continua gave to what is commonly known as a PHG. #### **Time synchronization** -The time synchronization is mapped as follows: - - - Device.property.type.coding.code="68220" - - Device.property.type.coding.system="urn.iso.std.iso:11073:10101" - - Device.property.type.text="MDC_TIME_SYNC_PROTOCOL" *(optional)* - - Device.property.valueCode.coding.code="*32-bit code for sync method*" - - Device.property.valueCode.coding.system="urn.iso.std.iso:11073:10101" - - Device.property.valueCode.text="*the ref id*" *(optional)* - - The 32-bit code for the time synchronization method is given by one of the following values: - -|32-bit code|Reference identifier| description |partition:term code| -|- -|532224 |MDC_TIME_SYNC_NONE |An uncalibrated and unsynchronized local clock source |8::7936| -|532234 |MDC_TIME_SYNC_EBWW |A manually set time, by ‘eyeball and wristwatch’ |8::7946| -|532225 |MDC_TIME_SYNC_NTPV3 |Network Time Protocol Version 3.0 (RFC 1305) |8::7937| -|532226 |MDC_TIME_SYNC_NTPV4 |Network Time Protocol Version 4.0 (under dev) |8::7938| -|532227 |MDC_TIME_SYNC_SNTPV4 |Simple Network Time Protocol v4 (RFC 2030) |8::7939| -|532228 |MDC_TIME_SYNC_SNTPV4330 |Simple Network Time Protocol v4 (RFC 4330) |8::7940| -|532229 |MDC_TIME_SYNC_BTV1 |Bluetooth Medical Device Profile |8::7941| -|532235 |MDC_TIME_SYNC_USB_SOF |Synced to the 1kHz USB "start-of-frame" clock|8::7947| -|532230 |MDC_TIME_SYNC_RADIO |Atomic Clock synchronization through RF |8::7942| -|532231 |MDC_TIME_SYNC_HL7_NCK |Synchronized via Health Level 7 NCK (network clock)|8::7943| -|532232 |MDC_TIME_SYNC_CDMA CDMA |mobile telecommunications synchronization |8::7944| -|532233 |MDC_TIME_SYNC_GSM |GSM - Network Identity and Time Zone (NITZ) |8::7945| -|532236 |MDC_TIME_SYNC_OTHER |A time sync method that has no known MDC code |8::7948| -|532237 |MDC_TIME_SYNC_OTHER_MOBILE |A time sync method based on other mobile network technology that is not listed above |8::7949| -|532238 |MDC_TIME_SYNC_GPS |A time sync method based on GPS information |8::7950| - -### **Remaining Optional Data** -The treatment of fields that would be in mock System-Model, Production-Specification, Reg-Cert-Data-List, and Mds-Time-Info attributes is the same as in the Phd Device Profile. However, there is an extra set of information in the mock Reg-Cert-Data-List regarding the certified Health & Fitness Service (H&FS) interfaces. A PHG has both PHD and H&FS interfaces. - -Text elements are always optional. - -If these fields are encoded they shall be encoded as follows: - -### **Specializations** -The specializations supported by the PHG may be reported. If reported, they shall be reported in the Device.specializations element for each specialization as follows: - - - specialization.systemType.coding.code="*32-bit specialization code*" - - specialization.systemType.coding.system="urn.iso.std.iso:11073:10101" - - specialization.systemType.text"*reference-id plus additional text*" - - specialization.version="*specialization version*" +The time synchronization is mapped to a device property element with as type the MDC code 68220. The possible codes for the time synchronization method come from the [MDC Time Synchronization Methods value set](ValueSet-MDCTimeSyncMethodCodes.html). + +#### **Remaining Optional Data** +The treatment of further optional information in a mock SystemInfo object is similar as in the Phd Device Profile. + +If these fields are present they shall be encoded as follows: + +##### **Specializations** +The specializations supported by the PHG may be reported. If reported, they shall be reported in the Device.specializations element for each specialization in the same way as in the Phd Device Profile. The `specialization.systemType` element is populated with the MDC code for the specialization and the `specialization.version` element is populated with the version of the specialization. If the PHG supports multiple versions of the specialization and the uploader wants to report this information, additional specializations entries for the additional versions are made. Alternatively the uploader can leave the version field empty. -A PHG is often designed to support all current and future PHDs that support a given version of the 11073-20601 standard. Instead of listing all the specializations individually (which could greatly increase the size of the message) one can use the 'generic' device code. In this case, the specialization.version element, if populated, indicates the version of the 20601 standard. If multiple versions of the 20601 standard are supported and the uploader wants to report this information, a separate 'generic' entries for each version are reported. Alternatively, the version element can be left empty. +A PHG is often designed to support all current and future PHDs that support a given version of the IEEE 11073-10206 standard. Instead of listing all the specializations individually (which could greatly increase the size of the message) one can use the 'generic' device code. In this case, the `specialization.version` element, if populated, indicates the version of the IEEE 11073-10206 standard. If multiple versions of the IEEE 11073-10206 standard are supported and the uploader wants to report this information, a separate 'generic' entries for each version are reported. Alternatively, the version element can be left empty. An example of generic code use would be as follows @@ -61,142 +29,28 @@ An example of generic code use would be as follows All defined IEEE PHD device specializations can be found in the [MDC Device Types value set](ValueSet-DeviceTypes11073MDC.html). -### **PHG Product Information** -The table blow provides codes and reference identifiers used in mapping the product information: - -|IEEE 11073-20601 Attribute|description|MDC code|MDC reference identifier| -|- -|System-Model|Model number|531969|MDC_ID_MODEL_NUMBER| -|System-Model|Manufacturer name|531970|MDC_ID_MODEL_MANUFACTURER| -|Production-Specification|Unspecified| 531971|MDC_ID_PROD_SPEC_UNSPECIFIED| -|Production-Specification|Serial number| 531972|MDC_ID_PROD_SPEC_SERIAL| -|Production-Specification|Part number| 531973|MDC_ID_PROD_SPEC_PART| -|Production-Specification|Hardware revision| 531974|MDC_ID_PROD_SPEC_HW| -|Production-Specification|Software revision| 531975|MDC_ID_PROD_SPEC_SW| -|Production-Specification|Firmware revision| 531976|MDC_ID_PROD_SPEC_FW| -|Production-Specification|Protocol revision| 531977|MDC_ID_PROD_SPEC_PROTOCOL| -|Production-Specification|Global Medical Device Nomenclature (GMDN)| 531978|MDC_ID_PROD_SPEC_GMDN| -|Reg-Cert-Data-List|Continua version|532352|MDC_REG_CERT_DATA_CONTINUA_VERSION| -|Reg-Cert-Data-List|Continua Certified Device List|532353|MDC_REG_CERT_DATA_CONTINUA_CERT_DEV_LIST| -|Reg-Cert-Data-List|Regulation status|532354|MDC_REG_CERT_DATA_CONTINUA_REG_STATUS | -|*PHG only*|Continua Certified H&FS List|532355|MDC_REG_CERT_DATA_CONTINUA_AHD_CERT_LIST| -|Mds-Time-Info|Synchronization method|68220|MDC_TIME_SYNC_PROTOCOL| -|Mds-Time-Info|Time capabilities|68219|MDC_TIME_CAP_STATE| -|Mds-Time-Info|High resolution relative time resolution|68224|MDC_TIME_RES_REL_HI_RES| -|Mds-Time-Info|Relative time resolution|68223|MDC_TIME_RES_REL| -|Mds-Time-Info|Absolute Time time resolution|68222|MDC_TIME_RES_ABS| -|Mds-Time-Info|Base offset time resolution|68226|MDC_TIME_RES_BO| -|Mds-Time-Info|Time synchronization accuracy|68221|MDC_TIME_SYNC_ACCURACY| - -#### **Primitives** - - - manufacturer="*PHG manufacturer*" - - modelNumber="*PHG model number*" - - serialNumber="*serial number*" - - partNumber="*part number*" - -#### **Hardware, Software, Firmware, Protocol, and Continua Versions** - - hardware - - version.type.coding.code="531974" - - version.type.coding.system="urn.iso.std.iso:11073:10101" - - version.type.text="MDC_ID_PROD_SPEC_HW + optional text" - - version.value="*hardware-version*" - - - software - - version.type.coding.code="531975" - - version.type.coding.system="urn.iso.std.iso:11073:10101" - - version.type.text="MDC_ID_PROD_SPEC_SW + optional text" - - version.value="*software-version*" - - - firmware - - version.type.coding.code="531976" - - version.type.coding.system="urn.iso.std.iso:11073:10101" - - version.type.text="MDC_ID_PROD_SPEC_FW + optional text" - - version.value="*firmware-version*" - - - protocol - - version.type.coding.code="531977" - - version.type.coding.system="urn.iso.std.iso:11073:10101" - - version.type.text="MDC_ID_PROD_SPEC_PROTOCOL + optional text" - - version.value="*protocol-version*" (Not IEEE 11073-20601 protocol!) - - - Continua - - version.type.coding.code="532352" - - version.type.coding.system="urn.iso.std.iso:11073:10101" - - version.type.text="MDC_REG_CERT_DATA_CONTINUA_VERSION + optional text" - - version.value="*Continua Version*" - -The Continua version has a major and minor component separated by a dot (.). For example, "6.1" where "6" is the major version and "1" is the minor version. - -#### **Continua Certified PHD interfaces** -The Continua *certified* PHD (Personal Area Network) interfaces are represented as a list of Continua-specified 'PHD' codes. Note there is a difference between certified PHD interfaces and supported PHD interfaces. The Continua-specified certification codes are a combination of a transport 'Tcode' and a specialization code which is based on the 16-bit term code of the MDC code for the specialization. The PHD code is generated by - - PHDCode = Tcode * 8192 + (specialization term code - 4096) - -The transport 'Tcodes' are as follows: - -|Tcode|Transport| -|- -|0|Continua version 1.0| -|1|USB| -|2|Bluetooth HDP| -|3|ZigBee| -|4|Bluetooth Low Energy| -|5|NFC| - -The special Tcode of 0 is for Continua version 1.0 when there was no transport component in the reported certified PHD interface codes. - -The PHDCodes are mapped to a list of property.valueCode elements. The property.type element, which identifies the property, is given by the MDC 32-bit code 532353. Its reference id is MDC_REG_CERT_DATA_CONTINUA_CERT_DEV_LIST. - - - property.type.coding.code="532353" - - property.type.coding.system="urn.iso.std.iso:11073:10101" - - property.type.text="MDC_REG_CERT_DATA_CONTINUA_CERT_DEV_LIST + text" - - property.valueCode*N*.coding.code="PHDCode*N*" - - property.valueCode*N*.coding.system="http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaPHDInterfaceIDs " - -Note that the property.valueCode element is an array and one can have many of these in a single property element. - -#### **Continua Certified Health & Fitness interfaces** -The Continua *certified* Health and Fitness interfaces are represented as a list of Continua-specified 'H&FS' codes as follows: - -|Health & Fitness Interface|H&FS 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| - -The Health and Fitness codes are mapped to a list of property.valueCode elements. The property.type element, which identifies the property, is given by the MDC 32-bit code 532355. Its reference id is MDC_REG_CERT_DATA_CONTINUA_AHD_CERT_DEV_LIST. - - - property.type.coding.code="532355" - - property.type.coding.system="urn.iso.std.iso:11073:10101" - - property.type.text="MDC_REG_CERT_DATA_CONTINUA_AHD_CERT_DEV_LIST + text" - - property.valueCode*N*.coding.code="H&FSCode*N*" - - property.valueCode*N*.coding.system="http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaHFS " - -#### **Regulation Status** -The PHG regulation status is reported as follows: - - - property.type.coding.code="532354.0" - - property.type.coding.system="http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7" - - property.type.display="negated-regulation-status" - - property.valueBoolean="true=unregulated false=regulated" - -One could enter some time capabilities as additional 'bits' components if desired. +##### **PHG Product Information** +The PHG product information is reported in the same way as in the Phd Device Profile for the following elements: + + - `Device.manufacturer` = *manufacturer name* + - `Device.modelNumber` = *model number* + - `Device.serialNumber` = *serial number* + - `Device.version` = *version* (optional) + + +##### **Continua Certified PHD interfaces** +The list of Continua Certified PHD interfaces can be provided by PHGs based on the IEEE 11073-20601 standard. It is not supported by the IEEE 11073-10206 ACOM standard. It is the complement of the same attribute in the Phd Device Profile and encoded in `property` elements in the same way. + +##### **Continua Certified Health & Fitness interfaces** +The list of Continua Certified PHD interfaces can be provided by PHGs based on the IEEE 11073-20601 standard. It is not supported by the IEEE 11073-10206 ACOM standard. + +The Health and Fitness codes are mapped to a list of `property` elements. The codes are from the [MDC Health and Fitness Codes value set](ValueSet-MDCHealthFitnessCodes.html). + +##### **Regulation Status** +The PHG regulation status is reported in the same way as in the Phd Device Profile. + +##### **Further time capabilities** +One could enter further time capabilities as additional `property` elements similar to those of a PHD if desired. -#### **Time Synchronization Accuracy** -The time synchronization accuracy is reported in microseconds as follows: - - Device.property.type.coding.code="68221" - - Device.property.type.coding.system="urn.iso.std.iso:11073:10101" - - Device.property.type.text="MDC_TIME_SYNC_ACCURACY" *(optional)* - - Device.property.valueQuantity.value="*time-sync-accuracy*" - - Device.property.valueQuantity.system="http://unitsofmeasure.org" - - Device.property.valueQuantity.code="us" (UCUM code for microseconds) - -### Examples: -An example of an Android PHG mapping is given [here](Device-phg-example.html) diff --git a/input/intro-notes/ValueSet-DeviceTypes11073MDC-intro.md b/input/intro-notes/ValueSet-DeviceTypes11073MDC-intro.md index 8a07405..4eb8546 100644 --- a/input/intro-notes/ValueSet-DeviceTypes11073MDC-intro.md +++ b/input/intro-notes/ValueSet-DeviceTypes11073MDC-intro.md @@ -1,5 +1,5 @@ ValueSet for the ISO/IEEE 11073-10101 Nomenclatures Describing Device specialization types such as blood pressure, pulse oximeter, thermometer, ECG, etc.. This value set will grow as new specializations are defined. -Most of the codes included in this value set are from partition 'infra' which has value 8. The 32-bit code for the pulse oximeter, which has term code 4100 in partition 'infra', is given by 524288 + 4100 = 528388. +Most of the codes included in this value set are from partition 'infra' which has value 8. The display value consists of the nomenclature code's reference identifier. Devices exchange the numerical codes as defined in the IEEE 11073-10101 standard, not reference identifiers, but the reference identifiers are often used where human readability are more important than efficiency or bandwidth. However, only the numerical codes are guaranteed to be unique. diff --git a/input/pagecontent/CodeableConcepts.md b/input/pagecontent/CodeableConcepts.md index bc02a0b..f273900 100644 --- a/input/pagecontent/CodeableConcepts.md +++ b/input/pagecontent/CodeableConcepts.md @@ -1,11 +1,11 @@ In this guide there will be several instances where the IEEE 11073-10101 nomenclature (MDC) codes are mapped to FHIR. In almost all cases this mapping involves an element that is a `CodeableConcepts` data type. The mapping is as follows: - - `CodeableConcept.coding.code` = *partition* * 2<sup>16</sup> + *term code* + - `CodeableConcept.coding.code` = MDC code (decimal value) - `CodeableConcept.coding.system` = urn:iso:std:iso:11073:10101 - `CodeableConcept.display` = reference identifier (*optional*) -The reference identifier in the display element is optional since the uploader may not know what the code means; for example, if the uploader works with a PHD specialization developed after the uploader had been released. However, this guide encourages that the display element contains at least the reference identifier for the MDC code if it is known. +The reference identifier in the `display` element is optional since the uploader may not know what the code means; for example, if the uploader works with a PHD specialization developed after the uploader had been released. However, this guide encourages that the `display` element contains at least the reference identifier for the MDC code if it is known. -The display element itself is also optional for future compatibility. Any display element entry requires that the uploader have previous knowledge of the code as display information is not provided by protocol. +The `display` element itself is also optional for future compatibility. Any `display` element entry requires that the uploader have previous knowledge of the code as display information is not provided by protocol. The `text` element can also used to provide additional information about the used code. An option is that the `text` element is populated with the reference identifier followed by additional implementation-defined text describing the code which may be in the local language. For example, `"MDC_CTXT_GLU_MEAL: Meal associated with measurement"`. diff --git a/input/pagecontent/DefinitionMetricMsmt.md b/input/pagecontent/DefinitionMetricMsmt.md index b76cb67..915361c 100644 --- a/input/pagecontent/DefinitionMetricMsmt.md +++ b/input/pagecontent/DefinitionMetricMsmt.md @@ -6,7 +6,7 @@ border-collapse:collapse; padding: 6px;}</style> |Measurement Attribute|Description| -|- +|---|---| |Basic-Nu-Observed-Value|Contains a single number encoded as an Mder SFLOAT\*| |Simple-Nu-Observed-Value|Contains a single number encoded as a Mder FLOAT\*| |Compound-Basic-Nu-Observed-Value|Contains multiple numbers encoded as Mder SFLOATs\*| diff --git a/input/pagecontent/ObtainObservationCode.md b/input/pagecontent/ObtainObservationCode.md index 74481df..0f41635 100644 --- a/input/pagecontent/ObtainObservationCode.md +++ b/input/pagecontent/ObtainObservationCode.md @@ -13,7 +13,7 @@ The `Observation.code` element is populated as follows: The requirement for the MDC reference identifier is not mandatory and is not used as the `Observation.code.coding.code` value because the reference identifier is not provided by the sensor device in the exchange protocol. Requiring the reference identifier would require that the PHG have an internal map. However, the main reason for not requiring the reference identifier is that doing so would defeat future interoperability. An older PHG would not know the reference identifier of a new specialization but it would be able to propagate the new code since that is provided by the device. -The MDC code entry is required, but the concept may be expressed in additional coding systems as well. The choice of any additional codings is up to the application. PHGs operating in certain realms may be required to provide translations to a realm-specified coding system. For example, in the United States realm, LOINC is strongly preferred. For those implementing a PHG for operations in the US, a mapping table for MDC to LOINC can be downloaded [here](https://loinc.org/file-access/download-id/9385/). +The MDC code entry is required, but the concept may be expressed in additional coding systems as well. The choice of any additional codings is up to the application. PHGs operating in certain realms may be required to provide translations to a realm-specified coding system. For example, in the United States realm, LOINC is strongly preferred. [RTMMS](https://rtmms.nist.gov/) contains a mapping for a subset of the MDC codes. The consumer of FHIR resources containing the PHD data does not need to concern itself with this complexity. All it needs to do is obtain the `Observation.code.coding.code` element supporting the 11073-10101 system value to get the measurement type. diff --git a/input/pagecontent/ObtainUnitCode.md b/input/pagecontent/ObtainUnitCode.md index 96720f3..cecf401 100644 --- a/input/pagecontent/ObtainUnitCode.md +++ b/input/pagecontent/ObtainUnitCode.md @@ -3,6 +3,6 @@ Observations and Observation Components that report quantities (Numerics and Sam Obtaining the unit in most cases is as simple as decoding the Unit-Code attribute. IEEE 11073-10206 ACOM unit codes are MDC values from partition 4 of IEEE 11073-10101. The FHIR encoder need to map these codes to the appropriate UCUM codes. -A mapping can be found in the [RTMMS](https://rtmms.nist.gov/rtmms/index.htm) and in the latest version of IEEE 11073-10101. +A mapping can be found in the [RTMMS](https://rtmms.nist.gov/) and in the latest version of IEEE 11073-10101. -In case the rare situation arises where a new unit has been introduced or the PHD uses a unit code that has not been previously used in PHD specializations, the FHIR encoder may use the MDC code in place of the UCUM code. In that case the FHIR encoder will need to create the 32-bit code from the 16-bit term code and the assumed partition value of 4. +In case the rare situation arises where a new unit has been introduced or the PHD uses a unit code that has not been previously used in PHD specializations, the FHIR encoder may use the MDC code in place of the UCUM code. diff --git a/input/pagecontent/ProfileConsumers.md b/input/pagecontent/ProfileConsumers.md index 4b10688..6911226 100644 --- a/input/pagecontent/ProfileConsumers.md +++ b/input/pagecontent/ProfileConsumers.md @@ -399,7 +399,7 @@ In IEEE 11073-10206 ACOM specializations are, in addition to a general descripti A table of some of the most common specializations can be found in the specialization section [here](StructureDefinition-PhdDevice.html). The example below shows an example of a PHD following the Glucose specialization: -{% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON EXCEPT:specialization %} +{% fragment Device/phd-00601900010E9234.F45EABA80832 JSON EXCEPT:specialization %} #### Property @@ -426,30 +426,8 @@ The `Device.type` is a CodeableConcept which tells what the property is. There a There will always be a time synchronization entry. It is identified by a property.type.coding.code="68220". It indicates the method the PHD uses to externally synchronize to a time reference. The value is a single valueCode entry. MDC codes express the possible synchronization methods. A table of the possible codes can be found in the time synchronization section [here](StructureDefinition-PhdDevice.html). This value is always TIME_SYNC_NONE (532224) if the PHD is not synchronized or has no time clock at all. To date ALL PHDs have no external time synchronization capabilities and this entry is always TIME_SYNC_NONE. An example of time synchronization property entry is shown below: -{% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON EXCEPT:property[0] %} - - { - "type" : { - "coding" : [ - { - "system" : "urn:iso:std:iso:11073:10101", - "code" : "68220" - } - ], - "text": "MDC_TIME_SYNC_PROTOCOL: Time synchronization protocol" - }, - "valueCode" : [ - { - "coding" : [ - { - "system" : "urn:iso:std:iso:11073:10101", - "code" : "532224" - } - ], - "text": "MDC_TIME_SYNC_NONE: No time synchronization" - } - ] - } +{% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON EXCEPT:property[4] %} + ##### Time Capabilities The time capabilities defines the types of real time clocks supported, whether the time can be set, whether external time synchronization is possible, etc. Each capability is treated as an event, so most PHGs will only report the capability if the PHD indicates it has the capability. The value is a single valueCode which will be either "Y" if the PHD has the capability or "N" if not. Most PHGs will not report the "N" case as that would significantly increase the size of the resource on the wire. There may be several such time capability property entries. @@ -458,7 +436,7 @@ The time capabilities property is indicated by the `Device.code` having one of t The example below gives the time capabilities of a market pulse oximeter: -{% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON ELIDE:property[2]|property[3]|property[4]|property[5] %} +{% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON ELIDE:property[5]|property[6]|property[7] %} #### Time Clock Resolutions The time clock resolutions is given by one of four MDC codes for each of the possible types of time clocks. Note that a PHD can only simultaneously support an absolute time (wall clock time with no offset) or base offset time (wall clock time with offset). A PHD may support both relative time clocks thus there could be up to three separate time resolution property entries though in most cases there is only one clock. @@ -467,56 +445,14 @@ The resolution value is a valueQuantity and it gives the time interval between c The property is indicated by the `Device.code` having one of four MDC codes "68222, 68223, 68224, and 68226". The value is a valueQuantity. -An example of a time resolution property for an absolute time clock with a time resolution of of one second is shown below: -{% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON EXCEPT:property[0] %} - { - "type": { - "coding": [ - { - "system": "urn:iso:std:iso:11073:10101", - "code": "68222" - } - ], - "text": "MDC_TIME_RES_ABS: absolute time clock resolution" - }, - "valueQuantity": [ - { - "value": 1000000, - "system": "http://unitsofmeasure.org", - "code": "us" - } - ] - } +An example of a time resolution property for a relative time clock with a time resolution of of one second is shown below: +{% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON EXCEPT:property[8] %} + #### Time Tick Resolution for R-R Intervals This section is only relevant for PHDs that support the Heart Rate or ECG specializations based on IEEE 11073-20601. It is not used for measurement timestamps but for measuring R-R intervals (time between electrocardiogram R-wave peaks) in ECG and Heart Rate specializations. The time tick resolution is a high frequency clock that is used to measure the time between R-wave peaks in an ECG trace. The number of ticks is reported in the `valueQuantity.value` element in Observations, not the effective[x] which is the time the measurement is taken. These special clocks typically have a resolution of 1024 Hz or better. When R-R intervals are reported, they are reported in units of these ticks, so one must know what the frequency of the clock is. The reason for this special clock is that R-R intervals have been traditionally timed using dedicated crystal oscillators. -The time tick is given as a property and its units are Hertz. However, the R-R interval is given in the number of these ticks and many PHGs will not make the conversion as there is no UCUM code for the MDC dimension code of Ticks and therefore the units reported will be the MDC unit of ticks. Thus the reader will have to obtain the R-R interval using the R-R reported tick value and the tick frequency given in the Device property element. - -The property is indicated by the `Device.code` having the MDC code "68229". The value is a valueQuantity. - -An example of the Tick resolution property entry for a 1024 Hz clock is given below. - - { - "type": { - "coding": [ - { - "system": "urn:iso:std:iso:11073:10101", - "code": "68229" - } - ], - "text": "MDC_ATTR_TICK_RES: Frequency of ticks" - }, - "valueQuantity": [ - { - "value": 976.5625, - "system": "http://unitsofmeasure.org", - "code": "us" // microseconds - } - ] - } - ACOM-based ECGs do not use the time tick resolution to report R-R intervals. #### Regulation Status @@ -526,7 +462,7 @@ The property is indicated by the `Device.code` having the ASN1ToHL7 code "532354 An example of an entry for an FDA regulated device is shown below: -{% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON BASE:property.where(type.coding.code='532354.0') %} +{% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON ELIDE:property[3] %} #### Continua Certified PHD Interfaces This property contains a code that indicates a specialization and transport the PHD has been (self-)certified for. Note there is a difference between 'support' and 'certified' support. The Device specialization entries indicate what the PHD supports. Certified means the PHD has been (independently) placed through a set of extensive tests for the specialization and the transport over which the specialization operates. In the past, the Continua organization certified PHDs for compliance to its guidelines that referenced this IG. @@ -535,7 +471,7 @@ The property is indicated by the `Device.code` having the MDC code "532353". The An example of a property entry where a PHD is certified for the pulse oximeter specialization over both Bluetooth Low Energy, USB, and Continua version 1.0 where there was no transport indicated, is given below: -{% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON BASE:property.where(type.coding.code='532353') %} +{% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON ELIDE:property[0] %} ### The PHG Device Resource The PHG Device Resource, can, in theory have all the same entries as in the PHD Device Resource plus one additional property that gives the list of certified Health and Fitness interfaces (to downstream servers). A PHG can be certified for both proper operation with PHD specializations as well as proper operation with downstream servers. One of those 'Health and Fitness' interfaces is the upload to RESTFul FHIR servers. Some PHGs also support uploads of the data as PCD-01 and some support questionnaires. @@ -549,7 +485,7 @@ Only the entries that are different from the PHD are discussed in the following #### Device Type This field states that the device is a PHG. This IG uses the MDC code MDC_MOC_VMS_MDS_AHD that indicates a gateway. "AHD" stands for Application Hosting Device and is the name Continua gave to what is commonly known as a PHG. -#### Certified Health and Fitness Interfaces +#### Continua Certified Health and Fitness Interfaces This property is a list of codes that indicate which Health and Fitness interfaces the PHG has been *certified* for. There is no certification body active for this IG, so this entry can be populated with interfaces the PHG supports. The property is indicated by the `Device.code` having the MDC code "532355". The value is a list of valueCodes where the codes come from the [ContinuaHFS](CodeSystem-ContinuaHFS.html) code system. The code system is simple and limited to only eight values at the current time. @@ -559,7 +495,7 @@ An example of a PHG resource is given [here](Device-phg-example.html). ### Patient Resource It is assumed here that the reader has access to the Patient resource uploaded by the PHG and that the PHG uploaded a Patient resource. There is a special case where the PHG will not upload a Patient resource. -The Patient resource is following the Phd Patient Profile as defined [here](StructureDefinition-PhdPatient.html). +The uploaded Patient resource is following the Phd Patient Profile as defined [here](StructureDefinition-PhdPatient.html). There is only one additional required entry in the Phd Patient Profile; the Patient.identifier. From c396385092a2608a6f0dd2e364dc570d5dc704f8 Mon Sep 17 00:00:00 2001 From: Erik Moll <erik.moll@philips.com> Date: Mon, 21 Jul 2025 12:26:44 +0200 Subject: [PATCH 07/10] further -20601 clean-up --- FHIR-phd.xml | 24 +++--- input/PhdImplementationGuide.xml | 58 ++------------ input/examples/bundle-example-1.json | 4 +- input/examples/meal-context-observation.json | 2 +- input/examples/numeric-spo2-alarm.json | 2 +- input/examples/numeric-spotnumeric.json | 2 +- input/examples/patientExample-1.json | 2 +- ...StructureDefinition.PhdBaseObservation.fsh | 10 +-- input/fsh/StructureDefinition.PhdDevice.fsh | 1 - ...uctureDefinition.PhdNumericObservation.fsh | 5 +- input/fsh/StructureDefinition.PhgDevice.fsh | 75 ------------------- .../fsh/ValueSet.CodeableConcept11073MDC.fsh | 15 ---- input/fsh/ValueSet.Quantity11073MDC.fsh | 19 ----- input/fsh/ValueSet.Range11073MDC.fsh | 13 ---- input/ignoreWarnings.txt | 3 - ...tureDefinition-PhdBaseObservation-notes.md | 4 +- ...ion-PhdCompoundNumericObservation-notes.md | 2 +- ...Definition-PhdCompoundObservation-notes.md | 2 +- .../StructureDefinition-PhdDevice-notes.md | 4 +- ...eDefinition-PhdNumericObservation-notes.md | 4 +- .../StructureDefinition-PhgDevice-notes.md | 8 +- input/pagecontent/CodeableConcepts.md | 11 --- input/pagecontent/DIMtoFHIRMapping.md | 2 +- input/pagecontent/DIMtoFHIRMappingDetails.md | 14 ---- input/pagecontent/DefinitionMetricMsmt.md | 45 ----------- input/pagecontent/MderFLOATsandSFLOATs.md | 2 +- .../MetricAttributesofNoInterest.md | 29 ------- input/pagecontent/Nomenclaturecodes.md | 39 +++++++++- input/pagecontent/ObtainObservationCode.md | 16 ++-- input/pagecontent/ObtainUnitCode.md | 8 -- input/pagecontent/ProfileConsumers.md | 10 +-- .../TechnicalImplementationGuidance.md | 12 +-- input/resources/ACME_Inc_PrivateMDCCodes.json | 2 +- 33 files changed, 97 insertions(+), 352 deletions(-) delete mode 100644 input/fsh/ValueSet.CodeableConcept11073MDC.fsh delete mode 100644 input/fsh/ValueSet.Quantity11073MDC.fsh delete mode 100644 input/fsh/ValueSet.Range11073MDC.fsh delete mode 100644 input/pagecontent/CodeableConcepts.md delete mode 100644 input/pagecontent/DIMtoFHIRMappingDetails.md delete mode 100644 input/pagecontent/DefinitionMetricMsmt.md delete mode 100644 input/pagecontent/MetricAttributesofNoInterest.md delete mode 100644 input/pagecontent/ObtainUnitCode.md diff --git a/FHIR-phd.xml b/FHIR-phd.xml index 4031530..f553330 100644 --- a/FHIR-phd.xml +++ b/FHIR-phd.xml @@ -20,7 +20,7 @@ <artifact deprecated="true" id="CodeSystem/ASN1ToHL7Concepts" key="CodeSystem-ASN1ToHL7Concepts" name="ASN1ToHL7Concepts"/> <artifact deprecated="true" id="ValueSet/ASN1attribute" key="ValueSet-ASN1attribute" name="ASN1attribute"/> <artifact deprecated="true" id="ValueSet/ASN1measurement" key="ValueSet-ASN1measurement" name="ASN1measurement"/> -<artifact id="ValueSet/CodeableConcept11073MDC" key="ValueSet-CodeableConcept11073MDC" name="CodeableConcept IEEE 11073-20601 Attributes"/> +<artifact deprecated="true" id="ValueSet/CodeableConcept11073MDC" key="ValueSet-CodeableConcept11073MDC" name="CodeableConcept11073MDC"/> <artifact id="StructureDefinition/CoincidentTimeStampReference" key="StructureDefinition-CoincidentTimeStampReference" name="Coincident Timestamp Reference"/> <artifact id="StructureDefinition/Confidence95" key="StructureDefinition-Confidence95" name="Confidence 95 range"/> <artifact id="CodeSystem/ContinuaDeviceIdentifiers" key="CodeSystem-ContinuaDeviceIdentifiers" name="Continua Device Identifiers"/> @@ -96,8 +96,8 @@ <artifact deprecated="true" id="StructureDefinition/PhdStringEnumerationObservation" key="StructureDefinition-PhdStringEnumerationObservation" name="PhdStringEnumerationObservation"/> <artifact id="StructureDefinition/PhdStringObservation" key="StructureDefinition-PhdStringObservation" name="PhdStringObservation"/> <artifact id="StructureDefinition/PhgDevice" key="StructureDefinition-PhgDevice" name="PhgDevice"/> -<artifact id="ValueSet/Quantity11073MDC" key="ValueSet-Quantity11073MDC" name="Quantity IEEE 11073-20601 Attributes"/> -<artifact id="ValueSet/Range11073MDC" key="ValueSet-Range11073MDC" name="Range 11073-20601 Attributes"/> +<artifact deprecated="true" id="ValueSet/Quantity11073MDC" key="ValueSet-Quantity11073MDC" name="Quantity11073MDC"/> +<artifact deprecated="true" id="ValueSet/Range11073MDC" key="ValueSet-Range11073MDC" name="Range11073MDC"/> <artifact id="ValueSet/SimpleAlertOperationalStates" key="ValueSet-SimpleAlertOperationalStates" name="Simple Alert Operational States Value Set"/> <artifact id="StructureDefinition/SimpleAlerting" key="StructureDefinition-SimpleAlerting" name="Simple Alerting"/> <artifact id="CodeSystem/SimpleAlertOperationalStatesCS" key="CodeSystem-SimpleAlertOperationalStatesCS" name="SimpleAlertOperationalStates CodeSystem"/> @@ -117,16 +117,16 @@ <page deprecated="true" key="BaseObservationProfile" name="Base Observation Profile"/> <page deprecated="true" key="bundleExample" name="Bundled upload of Patient, Device, and Observation resources"/> <page key="changes" name="Change Log"/> -<page key="CodeableConcepts" name="Codeable Concepts"/> +<page deprecated="true" key="CodeableConcepts" name="Codeable Concepts"/> <page deprecated="true" key="glucoseEnum" name="Coded Enumeration"/> <page deprecated="true" key="coinFault" name="Coincident Time Stamp with a time fault"/> <page deprecated="true" key="coincidentTime" name="Coincident Time Stamp: PHG best synchronized"/> <page key="CoincidentTimeStamp" name="Coincident Timestamp"/> <page deprecated="true" key="bloodPress" name="Compound Measurement"/> <page key="ProfileConsumers" name="Consuming the PHD Profile FHIR Resources"/> -<page key="DIMtoFHIRMapping" name="DIM to FHIR Mapping: Basics"/> -<page key="DIMtoFHIRMappingDetails" name="DIM to FHIR Mapping: Details"/> -<page key="DefinitionMetricMsmt" name="Definition of a Metric Measurement"/> +<page key="DIMtoFHIRMapping" name="DIM to FHIR Mapping"/> +<page deprecated="true" key="DIMtoFHIRMappingDetails" name="DIM to FHIR Mapping: Details"/> +<page deprecated="true" key="DefinitionMetricMsmt" name="Definition of a Metric Measurement"/> <page deprecated="true" key="DeviceIdentifierCodes" name="Device Identifier codes"/> <page deprecated="true" key="phdExample" name="Device example from a Blood Pressure PHD"/> <page deprecated="true" key="downloads" name="Downloads"/> @@ -136,14 +136,14 @@ <page deprecated="true" key="ContinuaPersonalAreaNetworkCodes" name="Generating the PHD codes"/> <page key="GenericModel" name="Generic and Extensible Model"/> <page key="Glossary" name="Glossary"/> -<page key="MderFLOATsandSFLOATs" name="Mder FLOATs and SFLOATs"/> -<page key="MetricAttributesofNoInterest" name="Metric Protocol-Only Attributes"/> +<page key="MderFLOATsandSFLOATs" name="IEEE 11073 FLOATs and SFLOATs"/> +<page key="Nomenclaturecodes" name="IEEE 11073-10101 MDC Nomenclature codes"/> +<page deprecated="true" key="MetricAttributesofNoInterest" name="Metric Protocol-Only Attributes"/> <page deprecated="true" key="NumericNaN" name="NaN Example"/> -<page key="Nomenclaturecodes" name="Nomenclature codes"/> <page deprecated="true" key="Non11073PHDDevices" name="Non IEEE 11073 PHD Devices"/> <page deprecated="true" key="Non1107320601Devices" name="Non IEEE 11073-20601 Devices"/> -<page key="ObtainObservationCode" name="Obtaining the Observation Code"/> -<page key="ObtainUnitCode" name="Obtaining the Unit Code"/> +<page deprecated="true" key="ObtainObservationCode" name="Obtaining the Observation Code"/> +<page deprecated="true" key="ObtainUnitCode" name="Obtaining the Unit Code"/> <page deprecated="true" key="Organization" name="Organization"/> <page key="Organizations" name="Organizations"/> <page deprecated="true" key="overview" name="Overview"/> diff --git a/input/PhdImplementationGuide.xml b/input/PhdImplementationGuide.xml index 976d6f0..ffbc4f1 100644 --- a/input/PhdImplementationGuide.xml +++ b/input/PhdImplementationGuide.xml @@ -228,24 +228,6 @@ In this example there are only xml structure definitions, value sets, code syste </reference> <exampleBoolean value="false"/> </resource> - <resource> - <reference> - <reference value="ValueSet/CodeableConcept11073MDC"/> - </reference> - <exampleBoolean value="false"/> - </resource> - <resource> - <reference> - <reference value="ValueSet/Quantity11073MDC"/> - </reference> - <exampleBoolean value="false"/> - </resource> - <resource> - <reference> - <reference value="ValueSet/Range11073MDC"/> - </reference> - <exampleBoolean value="false"/> - </resource> <resource> <reference> <reference value="ValueSet/MDCnotObject"/> @@ -545,7 +527,7 @@ In this example there are only xml structure definitions, value sets, code syste <nameUrl value="UseCases.html"/> <title value="Use Cases"/> <generation value="markdown"/> - </page> + </page> <page> <nameUrl value="ProfilesOverview.html"/> <title value="Profiles Overview"/> @@ -584,46 +566,17 @@ In this example there are only xml structure definitions, value sets, code syste </page> <page> <nameUrl value="DIMtoFHIRMapping.html"/> - <title value="DIM to FHIR Mapping: Basics"/> - <generation value="markdown"/> - </page> - <page> - <nameUrl value="DIMtoFHIRMappingDetails.html"/> - <title value="DIM to FHIR Mapping: Details"/> + <title value="DIM to FHIR Mapping"/> <generation value="markdown"/> - <page> - <nameUrl value="DefinitionMetricMsmt.html"/> - <title value="Definition of a Metric Measurement"/> - <generation value="markdown"/> - </page> - <page> - <nameUrl value="MetricAttributesofNoInterest.html"/> - <title value="Metric Protocol-Only Attributes"/> - <generation value="markdown"/> - </page> + <page> <nameUrl value="MderFLOATsandSFLOATs.html"/> - <title value="Mder FLOATs and SFLOATs"/> + <title value="IEEE 11073 FLOATs and SFLOATs"/> <generation value="markdown"/> </page> <page> <nameUrl value="Nomenclaturecodes.html"/> - <title value="Nomenclature codes"/> - <generation value="markdown"/> - </page> - <page> - <nameUrl value="CodeableConcepts.html"/> - <title value="Codeable Concepts"/> - <generation value="markdown"/> - </page> - <page> - <nameUrl value="ObtainObservationCode.html"/> - <title value="Obtaining the Observation Code"/> - <generation value="markdown"/> - </page> - <page> - <nameUrl value="ObtainUnitCode.html"/> - <title value="Obtaining the Unit Code"/> + <title value="IEEE 11073-10101 MDC Nomenclature codes"/> <generation value="markdown"/> </page> <page> @@ -631,6 +584,7 @@ In this example there are only xml structure definitions, value sets, code syste <title value="Generating the PHD Reported Timestamp Identifier"/> <generation value="markdown"/> </page> + </page> <page> <nameUrl value="CoincidentTimeStamp.html"/> diff --git a/input/examples/bundle-example-1.json b/input/examples/bundle-example-1.json index 7fc6b55..5775052 100644 --- a/input/examples/bundle-example-1.json +++ b/input/examples/bundle-example-1.json @@ -24,7 +24,7 @@ } ] }, - "system": "urn:oid:1.2.3.4.5.6.7.8.10", + "system": "urn:oid:2.999.1.2.3.4.5.6.7.8.10", "value": "sisansarahId" } ], @@ -40,7 +40,7 @@ "request": { "method": "POST", "url": "Patient", - "ifNoneExist": "identifier=urn:oid:1.2.3.4.5.6.7.8.10|sisansarahId" + "ifNoneExist": "identifier=urn:oid:2.9991.2.3.4.5.6.7.8.10|sisansarahId" } }, { diff --git a/input/examples/meal-context-observation.json b/input/examples/meal-context-observation.json index 454ece4..0fd473c 100644 --- a/input/examples/meal-context-observation.json +++ b/input/examples/meal-context-observation.json @@ -31,7 +31,7 @@ ], "identifier": [ { - "value": "00601900010E9234-sisansarahId-urn:oid:1.2.3.4.5.6.7.8.10-8417864-20170602150227.00", + "value": "00601900010E9234-sisansarahId-urn:oid:2.999.1.2.3.4.5.6.7.8.10-8417864-20170602150227.00", "system":"http://hl7.org/fhir/uv/phd/StructureDefinition/PhdBaseObservation" } ], diff --git a/input/examples/numeric-spo2-alarm.json b/input/examples/numeric-spo2-alarm.json index 4b97e35..386f27e 100644 --- a/input/examples/numeric-spo2-alarm.json +++ b/input/examples/numeric-spo2-alarm.json @@ -75,7 +75,7 @@ ], "identifier": [ { - "value": "74E8FFFEFF051C00-sisansarahId-urn:oid:1.2.3.4.5.6.7.8.10-149530-20181113175902.00-150588", + "value": "74E8FFFEFF051C00-sisansarahId-urn:oid:2.999.1.2.3.4.5.6.7.8.10-149530-20181113175902.00-150588", "system": "http://hl7.org/fhir/uv/phd/StructureDefinition/PhdBaseObservation" } ], diff --git a/input/examples/numeric-spotnumeric.json b/input/examples/numeric-spotnumeric.json index 9a810b6..d6a23f6 100644 --- a/input/examples/numeric-spotnumeric.json +++ b/input/examples/numeric-spotnumeric.json @@ -30,7 +30,7 @@ ], "identifier": [ { - "value": "74E8FFFEFF051C00-sisansarahId-urn:oid:1.2.3.4.5.6.7.8.10-149530-20181113175903.00-150588", + "value": "74E8FFFEFF051C00-sisansarahId-urn:oid:2.999.1.2.3.4.5.6.7.8.10-149530-20181113175903.00-150588", "system":"http://hl7.org/fhir/uv/phd/StructureDefinition/PhdBaseObservation" } ], diff --git a/input/examples/patientExample-1.json b/input/examples/patientExample-1.json index bfb3141..bee2225 100644 --- a/input/examples/patientExample-1.json +++ b/input/examples/patientExample-1.json @@ -16,7 +16,7 @@ } ] }, - "system": "urn:oid:1.2.3.4.5.6.7.8.10", + "system": "urn:oid:2.999.1.2.3.4.5.6.7.8.10", "value": "sisansarahId" } ], diff --git a/input/fsh/StructureDefinition.PhdBaseObservation.fsh b/input/fsh/StructureDefinition.PhdBaseObservation.fsh index 8de39b3..7b2120f 100644 --- a/input/fsh/StructureDefinition.PhdBaseObservation.fsh +++ b/input/fsh/StructureDefinition.PhdBaseObservation.fsh @@ -1,4 +1,3 @@ -Alias: $CodeableConcept11073MDC = http://hl7.org/fhir/uv/phd/ValueSet/CodeableConcept11073MDC Alias: $MDCValueSet = http://hl7.org/fhir/uv/phd/ValueSet/MDCValueSet Profile: PhdBaseObservation @@ -93,16 +92,17 @@ Description: "Common base profile with the elements that are common to the PHD I * component[supplementalTypesComponent] ^short = "Supplemental Type: A further description of the measurement type." * ^definition = "For each code contained in the Supplemental-Types attribute, a separate supplementalTypesComponent element is generated. The component is not generated if the attribute is absent or empty. The component shall be generated otherwise." * ^comment = "A PHD may send a Supplemental-Types attribute as part of the measurement. This attribute consists of a set of MDC nomenclature codes. Each code describes an aspect of the measurement, such as MDC_MODALITY_SPOT in the pulse oximeter which indicates that the provided measurement is a stable average." - * code from $CodeableConcept11073MDC (required) +// * code from $CodeableConcept11073MDC (required) + * code = Mdc#68193 // from $CodeableConcept11073MDC (required) * coding 1.. * system 1.. * system = "urn:iso:std:iso:11073:10101" (exactly) * code 1.. * code = #68193 (exactly) - * ^definition = "68193 is the MDC code indicating a 'Supplemental-Types' value" + * ^definition = "68193 is the 32-bit nomenclature code indicating a 'Supplemental-Types' value" * display ^definition = "It is recommended to display at least the reference identifier for the Supplemental-Types which is MDC_ATTR_SUPPLEMENTAL_TYPES" -// * value[x] 1.. -// * valueCodeableConcept 1..1 + + * value[x] only CodeableConcept * valueCodeableConcept // only CodeableConcept * coding * system 1.. diff --git a/input/fsh/StructureDefinition.PhdDevice.fsh b/input/fsh/StructureDefinition.PhdDevice.fsh index dcac569..4b11c39 100644 --- a/input/fsh/StructureDefinition.PhdDevice.fsh +++ b/input/fsh/StructureDefinition.PhdDevice.fsh @@ -1,5 +1,4 @@ Alias: $ASN1DeviceBits = http://hl7.org/fhir/uv/phd/ValueSet/ASN1DeviceBits -Alias: $CodeableConcept11073MDC = http://hl7.org/fhir/uv/phd/ValueSet/CodeableConcept11073MDC Profile: PhdDevice Parent: Device diff --git a/input/fsh/StructureDefinition.PhdNumericObservation.fsh b/input/fsh/StructureDefinition.PhdNumericObservation.fsh index 50121c7..aef72dd 100644 --- a/input/fsh/StructureDefinition.PhdNumericObservation.fsh +++ b/input/fsh/StructureDefinition.PhdNumericObservation.fsh @@ -1,4 +1,3 @@ -Alias: $CodeableConcept11073MDC = http://hl7.org/fhir/uv/phd/ValueSet/CodeableConcept11073MDC Alias: $ASN1DeviceBits = http://hl7.org/fhir/uv/phd/ValueSet/ASN1DeviceBits Profile: PhdNumericObservation @@ -16,8 +15,8 @@ Description: "Observations from a PHD where the measurement is number" * ^comment = "Used for non-compound numeric observations from Personal Health Devices." * value[x] only Quantity * value 1.. - * ^definition = "The decoded Mder FLOAT or SFLOAT value from a PHD measurement containing either a\r\nBasic-Nu-Observed-Value\r\nSimple-Nu-Observed-Value or\r\nNu_observed-Value attribute." - * ^comment = "The implicit precision in the value shall be honored. The Mder encoding used in the above attributes provides this precision. The translating software shall honor that precision when generating this value.\r\nThis element shall be present unless there is an error reported in the Measurement-Status attribute or the Nu-Observed-Value.status field or the Mder encoding represents one of the special values. In that case there is a dataAbsentReason element and the valueQuantity element is not present. Note that not all measurement status values are errors resulting in no measurement being reported here; for example the preliminary or verified status." + * ^definition = "The decoded FLOAT or SFLOAT value from a PHD measurement containing either a\r\nBasic-Nu-Observed-Value\r\nSimple-Nu-Observed-Value or\r\nNu_observed-Value attribute." + * ^comment = "The implicit precision in the value shall be honored. The MDER encoding used in the above attributes provides this precision. The translating software shall honor that precision when generating this value.\r\nThis element shall be present unless there is an error reported in the Measurement-Status attribute or the Nu-Observed-Value.status field or the Mder encoding represents one of the special values. In that case there is a dataAbsentReason element and the valueQuantity element is not present. Note that not all measurement status values are errors resulting in no measurement being reported here; for example the preliminary or verified status." * system 1.. * system = "http://unitsofmeasure.org" (exactly) * code 1.. diff --git a/input/fsh/StructureDefinition.PhgDevice.fsh b/input/fsh/StructureDefinition.PhgDevice.fsh index 8342234..6ee1529 100644 --- a/input/fsh/StructureDefinition.PhgDevice.fsh +++ b/input/fsh/StructureDefinition.PhgDevice.fsh @@ -1,7 +1,5 @@ Alias: $DeviceTypes11073MDC = http://hl7.org/fhir/uv/phd/ValueSet/DeviceTypes11073MDC Alias: $ASN1DeviceBits = http://hl7.org/fhir/uv/phd/ValueSet/ASN1DeviceBits -Alias: $Quantity11073MDC = http://hl7.org/fhir/uv/phd/ValueSet/Quantity11073MDC -Alias: $CodeableConcept11073MDC = http://hl7.org/fhir/uv/phd/ValueSet/CodeableConcept11073MDC Profile: PhgDevice Parent: Device @@ -184,76 +182,3 @@ Description: "Profile for the Device Resource for a PHG" * system = "http://terminology.hl7.org/CodeSystem/v2-0136" (exactly) * code 1.. * ^definition = "If bit is set, the device is not regulated. If cleared, the device is regulated." - - -// * property 1.. -// * ^slicing.discriminator[0].type = #value -// * ^slicing.discriminator[=].path = "type" -// * ^slicing.rules = #open -// * property contains -// bitProperties 0..* and -// quantitiesProperty 0..* and -// codedListProperties 0..* -// * property[bitProperties] ^short = "Properties reported in BITs fields" -// * ^definition = "For each bit setting reported a BITs value, a bitProperties element is used." -// * ^comment = "A BITs measurement is a 16 or 32-bit ASN1 BITs value where each bit means something. " -// * type from $ASN1DeviceBits (required) -// * ^short = "Tells what the BITs item is" -// * ^definition = "One of the capabilities reported in the Mds-Time-Info.mds-time-caps-state or Reg-Cert-Data-List.regulation-status field." -// * ^comment = "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" -// * coding 1..1 -// * ^short = "Required ASN1 code system entry" -// * system 1.. -// * system = "http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7" (exactly) -// * code 1.. -// * ^definition = "The ASN1 code made from the code and the Mder bit position" -// * ^comment = "The MDC code for the regulation status field 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. One could enter some fields of the time capabilities attribute if desired." -// * text ^definition = "It is recommended to display at least the ASN1 name for the given bit meaning" -// * valueQuantity ..0 -// * valueCode 1..1 -// * coding ^slicing.discriminator[0].type = #value -// * ^slicing.discriminator[=].path = "system" -// * ^slicing.rules = #open -// * coding contains V2Binary 1..1 -// * coding[V2Binary] ^short = "Required V2 Binary code system entry" -// * system 1.. -// * system = "http://terminology.hl7.org/CodeSystem/v2-0136" (exactly) -// * code 1.. -// * ^definition = "If bit is set, code contains Y if cleared, N" -// * property[quantitiesProperty] ^short = "The PHG properties represented by quantities such as time synchronization accuracy" -// * ^definition = "This element represents all those time properties that are a quantity such as the time synchronization accuracy." -// * ^comment = "For a PHG the synchronization accuracy should be reported if known." -// * type from $Quantity11073MDC (required) -// * ^short = "The type of time quantity" -// * coding 1.. -// * ^short = "Required MDC code system entry" -// * system 1.. -// * system = "urn:iso:std:iso:11073:10101" (exactly) -// * code 1.. -// * ^definition = "The MDC code representing the property" -// * ^comment = "For PHG only the time sync accuracy is of interest.\r\n\r\n Description CODE Reference Identifier\r\n ------------------------------------------------------------------------------------\r\n Absolute clock resolution 68222 MDC_TIME_RES_ABS\r\n Base-offset clock resolution 68226 MDC_TIME_RES_BO\r\n Relative time resolution 68223 MDC_TIME_RES_REL\r\n Hi Res relative time resolution 68224 MDC_TIME_RES_REL_HI_RES\r\n Time sync accuracy 68221 MDC_TIME_SYNC_ACCURACY\r\n" -// * text ^definition = "It is recommended to display at least the MDC reference identifier for the code" -// * valueQuantity 1..1 -// * ^definition = "The value of the reported quantity." -// * valueCode ..0 -// * property[codedListProperties] ^short = "The device properties represented by a list of codes such as the list of certified PHD or H-FS interfaces" -// * ^definition = "This element represents all those properties that are a list of codes. At the moment there is only certified PHD interfaces." -// * ^comment = "Continua certified PHDs are required to have these entries." -// * type from $CodeableConcept11073MDC (required) -// * ^short = "What the coded list is" -// * coding 1.. -// * ^short = "Required MDC code system entry" -// * system 1.. -// * system = "urn:iso:std:iso:11073:10101" (exactly) -// * code 1.. -// * ^definition = "The MDC code representing the property" -// * ^comment = "Currently PHDs support the reporting of one of the coded lists as shown in the Table. More may be added in the future\r\n\r\n Description CODE Reference Identifier Code System\r\n -----------------------------------------------------------------------------------------------------------------------------------\r\n Time synchronization 68220 MDC_TIME_SYNC_PROTOCOL\r Certified PHD interfaces 532353 MDC_REG_CERT_DATA_CONTINUA_CERT_DEV_LIST http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaPHDInterfaceIDs\r\n Certified HFS interfaces 532355 MDC_REG_CERT_DATA_CONTINUA_AHD_CERT_DEV_LIST http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaHFS\r\n" -// * text ^definition = "It is recommended to display at least the MDC reference identifier for the code" -// * valueQuantity ..0 -// * valueCode 1.. -// * ^short = "There shall be one valueCode entry for every item supported by the PHG in the list" -// * coding 1.. -// * system 1.. -// * ^definition = "Either the http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaPHDInterfaceIDs or http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaHFS or urn:iso:std:iso:11073:10101 code systems" -// * code 1.. -// * ^definition = "One of the Continua interface certification codes" \ No newline at end of file diff --git a/input/fsh/ValueSet.CodeableConcept11073MDC.fsh b/input/fsh/ValueSet.CodeableConcept11073MDC.fsh deleted file mode 100644 index ff8d4c8..0000000 --- a/input/fsh/ValueSet.CodeableConcept11073MDC.fsh +++ /dev/null @@ -1,15 +0,0 @@ -ValueSet: CodeableConcept11073MDC -Id: CodeableConcept11073MDC -Title: "CodeableConcept IEEE 11073-20601 Attributes" -Description: "ValueSet for the ISO/IEEE 11073-10101 Nomenclatures describing IEEE 11073-20601 DIM attributes whose values are codes and thus represented as Codeable Concepts." -* ^meta.profile = "http://hl7.org/fhir/StructureDefinition/shareablevalueset" -* ^url = "http://hl7.org/fhir/uv/phd/ValueSet/CodeableConcept11073MDC" -* ^version = "current" -// * ^status = #draft -* ^experimental = false -* ^date = "2018-11-23" -* ^publisher = "Health Level Seven International (Devices Work Group)" -* Mdc#68193 "Supplemental types" -* Mdc#68220 "Time synchronization method" -* Mdc#532353 "Continua certified PHD interfaces" -* Mdc#532355 "Continua certified Health and Fitness interfaces" diff --git a/input/fsh/ValueSet.Quantity11073MDC.fsh b/input/fsh/ValueSet.Quantity11073MDC.fsh deleted file mode 100644 index c860775..0000000 --- a/input/fsh/ValueSet.Quantity11073MDC.fsh +++ /dev/null @@ -1,19 +0,0 @@ -ValueSet: Quantity11073MDC -Id: Quantity11073MDC -Title: "Quantity IEEE 11073-20601 Attributes" -Description: "ValueSet for the ISO/IEEE 11073-20601 DIM attributes whose values are Quantities." -* ^meta.profile = "http://hl7.org/fhir/StructureDefinition/shareablevalueset" -* ^url = "http://hl7.org/fhir/uv/phd/ValueSet/Quantity11073MDC" -* ^version = "current" -// * ^status = #draft -* ^experimental = false -* ^date = "2018-11-23" -* ^publisher = "Health Level Seven International (Devices Work Group)" -* Mdc#68073 "High-resolution relative time" -* Mdc#67914 "Accuracy of Measurement" -* Mdc#68222 "Resolution of absolute time clock" -* Mdc#68226 "Resolution of Base offset time clock" -* Mdc#68223 "Resolution of relative time clock" -* Mdc#68224 "Resolution of high-resolution relative time clock" -* Mdc#68221 "Time synchronization accuracy" -* Mdc#68229 "Tick Resolution" diff --git a/input/fsh/ValueSet.Range11073MDC.fsh b/input/fsh/ValueSet.Range11073MDC.fsh deleted file mode 100644 index d10a60f..0000000 --- a/input/fsh/ValueSet.Range11073MDC.fsh +++ /dev/null @@ -1,13 +0,0 @@ -ValueSet: Range11073MDC -Id: Range11073MDC -Title: "Range 11073-20601 Attributes" -Description: "ValueSet for the ISO/IEEE 11073-20601 DIM attributes whose values are Ranges." -* ^meta.profile = "http://hl7.org/fhir/StructureDefinition/shareablevalueset" -* ^url = "http://hl7.org/fhir/uv/phd/ValueSet/Range11073MDC" -* ^version = "current" -// * ^status = #draft -* ^experimental = false -* ^date = "2018-11-23" -* ^publisher = "Health Level Seven International (Devices Work Group)" -* Mdc#67892 "Current limits" -* Mdc#68236 "Measurement confidence 95% range" diff --git a/input/ignoreWarnings.txt b/input/ignoreWarnings.txt index 6d17da0..6959c83 100644 --- a/input/ignoreWarnings.txt +++ b/input/ignoreWarnings.txt @@ -41,8 +41,5 @@ Reference to draft CodeSystem http://hl7.org/fhir/uv/pocd/CodeSystem/measurement Reference to draft CodeSystem urn:iso:std:iso:11073:10101|2024-12-05 from fhir.tx.support.r4#0.29.0 Reference to draft CodeSystem urn:iso:std:iso:11073:10101|2024-12-05 from fhir.tx.support.r4#0.30.0 -# This is a fake/example OID for a hospital and this warning can be ignored safely. -URL value 'urn:oid:1.2.3.4.5.6.7.8.10' does not resolve - # Publisher process choice - can safely be ignored The value set expansion is too large, and only a subset has been displayed \ No newline at end of file diff --git a/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md b/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md index 1266954..f250616 100644 --- a/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md +++ b/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md @@ -14,7 +14,7 @@ Additionally a globally unique identifier can be used in combination with a cond |---|---|---| |device|`PHD Device.identifier.value`|This value is a hexadecimal representation of the PHD system identifier (16 hexadecimal characters for the IEEE EUI-64 identifier, 12 for the EUI-48 transport address identifier)| |patient|`Patient.identifier.value`-`Patient.identifier.system` or<br/>provided logical id|The dashes are part of the identifier. <br/>When the service provider gives the PHG a pre-determined patient logical id the PHG creates no Patient resource and has no patient information. In that situation the provided logical id is used| -|type|`Observation.code.coding.code`|See [Obtaining the Observation.code](ObtainObservationCode.html) (decimal number)| +|type|`Observation.code.coding.code`|See [MDC Nomenclature codes](NomenclatureCodes.html) (decimal number)| |timestamp|`Observation.effectiveDateTime` or `Observation.effectivePeriod.start`|The reported PHD timestamp. See [Generating the PHD Reported Timestamp](GeneratingtheTimeStampPartIdentifier.html)| |duration|the length of `Observation.effectivePeriod`| See [Generating the PHD Reported Timestamp](GeneratingtheTimeStampPartIdentifier.html)| |Supplemental Information|`Observation.component.valueCodeableConcept.coding.code` |A sequence of MDC codes (decimal number) separated by a dash from the "supplemental information" components.| @@ -28,7 +28,7 @@ An example of the this identifier from [this example](Observation-numeric-spotnu {% fragment Observation/numeric-spotnumeric JSON EXCEPT:identifier %} ### Obtaining the Type of observation -One obtains the IEEE 11073-10101 observation type for the code element in the same manner for all metric observations. See the section [Obtaining the Observation.code](ObtainObservationCode.html) for the details of this mapping. +One obtains the IEEE 11073-10101 observation type for the code element in the same manner for all metric observations. See the section [MDC Nomenclature codes](NomenclatureCodes.html) for the details of this mapping. ### Subject The subject element normally points to the PhdPatient resource using the logical id of the Patient resource, for example 'Patient/123546'. For device settings known to the PHG it should point to the PHD. diff --git a/input/intro-notes/StructureDefinition-PhdCompoundNumericObservation-notes.md b/input/intro-notes/StructureDefinition-PhdCompoundNumericObservation-notes.md index a8fceaf..3809875 100644 --- a/input/intro-notes/StructureDefinition-PhdCompoundNumericObservation-notes.md +++ b/input/intro-notes/StructureDefinition-PhdCompoundNumericObservation-notes.md @@ -1,5 +1,5 @@ -A compound numeric observation reports a measurement value that is described by a set of multiple numbers such as the x, y, and z components of an acceleration. It is NOT used to report an array of measurements but only where the quantity being measured requires more than one number to describe it. Each individual entry of the compound value is reported in an Observation.component element. The encoding of each entry should indicate both precision and the number of significant figures. The Observation.component.valueQuantity.value element is required to honor the reported precision as indicated by the encoding. See the section [Mder FLOATs and SFLOATs](MderFLOATsandSFLOATs.html) for instructions on handling Mder S/FLOATs and their encoding to the valueQuantity. +A compound numeric observation reports a measurement value that is described by a set of multiple numbers such as the x, y, and z components of an acceleration. It is NOT used to report an array of measurements but only where the quantity being measured requires more than one number to describe it. Each individual entry of the compound value is reported in an Observation.component element. The encoding of each entry should indicate both precision and the number of significant figures. The Observation.component.valueQuantity.value element is required to honor the reported precision as indicated by the encoding. See the section [FLOATs and SFLOATs](MderFLOATsandSFLOATs.html) for instructions on handling IEEE 11073 FLOATs and their encoding to the valueQuantity. In IEEE 11073-20601 the Observation.component.code element is obtained from the Metric-Id-List attribute unless the measurement reported is a Compound-Nu-Observed-Value attribute. In that case the attribute itself has the metric type for each entry and that is used instead of the Metric-Id-List entries. The order of the entries in the Metric-Id-List are one-to-one with the order of the compound attribute entries. For example, if the Metric-Id-List in the Blood Pressure measurement has MDC codes for 'systolic", "diastolic" and "mean" in that order, the quantities in the compound attribute are the systolic, diastolic, and mean values, respectively. diff --git a/input/intro-notes/StructureDefinition-PhdCompoundObservation-notes.md b/input/intro-notes/StructureDefinition-PhdCompoundObservation-notes.md index a1cb609..1b89cfe 100644 --- a/input/intro-notes/StructureDefinition-PhdCompoundObservation-notes.md +++ b/input/intro-notes/StructureDefinition-PhdCompoundObservation-notes.md @@ -6,7 +6,7 @@ The Observation.code element comes from the Type attribute and gives the general There is no Observation.value[x] entry. There may still be an Observation.dataAbsentReason element if, say, the Measurement-Status attribute indicates an invalid or otherwise overall failure value. If there is such an overall failure of the measurement, then there is no need to report the components. -The FLOAT encoding of the numeric components indicates both precision and the number of significant digits. The Observation.component.valueQuantity.value element is required to honor the reported precision as indicated by the FLOAT. See the section [Mder FLOATs and SFLOATs](MderFLOATsandSFLOATs.html) for instructions on handling FLOATs and their encoding to the valueQuantity. +The FLOAT encoding of the numeric components indicates both precision and the number of significant digits. The Observation.component.valueQuantity.value element is required to honor the reported precision as indicated by the FLOAT. See the section [FLOATs and SFLOATs](MderFLOATsandSFLOATs.html) for instructions on handling FLOATs and their encoding to the valueQuantity. The structure definition is given [here](StructureDefinition-PhdCompoundObservation.html) diff --git a/input/intro-notes/StructureDefinition-PhdDevice-notes.md b/input/intro-notes/StructureDefinition-PhdDevice-notes.md index a34d854..72937c3 100644 --- a/input/intro-notes/StructureDefinition-PhdDevice-notes.md +++ b/input/intro-notes/StructureDefinition-PhdDevice-notes.md @@ -26,7 +26,7 @@ An example of a system identifier is: {% fragment Device/phd-74E8FFFEFF051C00.001C05FFE874 JSON EXCEPT:identifier %} ### UDI → `Device.udiCarrier` - The UDI is included as an optional attribute of a PHD in the IEEE 11073-10206 ACOM standard (and the older IEEE 11073-20601 standard). It is also supported in the Bluetooth SIG Device Information Service and the GHS Profile. The UDI elements supported are issuer, jurisdiction, Device Identifier, and the Human Readable Barcode String. The udiCarrier does have elements for each of these entries. The entryType code for this sourcing of the UDI `electronic-transmission` is used as the UDI is transmitted electronically. + The UDI is included as an optional attribute of a PHD in the IEEE 11073-10206 ACOM standard. It is also supported in the Bluetooth SIG Device Information Service and the GHS Profile. The UDI elements supported are issuer, jurisdiction, Device Identifier, and the Human Readable Barcode String. The udiCarrier does have elements for each of these entries. The entryType code for this sourcing of the UDI `electronic-transmission` is used as the UDI is transmitted electronically. The UDI of a device consists of a Device Identifier (DI) and a Production Identifier (PI). The DI is the part of the UDI that identifies the specific model of the device. The PI is used to identify the specific instance of the device, such as its serial number or lot number. When the PI includes a serial number it identifies a specific instance of the devices of the model as specified by the DI. @@ -55,7 +55,7 @@ The ACOM Manufacturer, System-Model and Serial Number attributes contains string The revision information provided by the PHD, such as the hardware-revision, is encoded in the `Device.version` element. The version information is provided as a list of versions, where each version has a type and a value. The type is encoded as an MDC code and the value is a string. The type codes are defined in the [MDC Device Version Type Codes ValueSet](ValueSet-MDCDeviceVersionTypes.html). ### Reg-Cert-Data-List -The Reg-Cert-Data-List can be provided by PHDs based on the IEEE 11073-20601 standard. It is not supported by the IEEE 11073-10206 ACOM standard. +The Reg-Cert-Data-List can be provided by older PHDs based on the IEEE 11073-20601 standard. It is not supported by the IEEE 11073-10206 ACOM standard. It contains the Continua version, list of certified PHD interfaces, and the regulation status. The Continua version is mapped to an additional `Device.version` element and the other two fields are mapped to a `Device.property` element. #### Reg-Cert-Data-List Certified PHD interfaces → `Device.property` diff --git a/input/intro-notes/StructureDefinition-PhdNumericObservation-notes.md b/input/intro-notes/StructureDefinition-PhdNumericObservation-notes.md index 1a66e1d..3b2ed57 100644 --- a/input/intro-notes/StructureDefinition-PhdNumericObservation-notes.md +++ b/input/intro-notes/StructureDefinition-PhdNumericObservation-notes.md @@ -1,7 +1,7 @@ -This profile is used to map ACOM Numeric Observations. The measured value is reported as a floating number with an optional accuracy. In GHS the value is encoded as an IEEE 11073 FLOAT that indicates both precision and the number of significant digits. The `Observation.valueQuantity.value` element is required to honor the reported precision. See [Mder FLOATs and SFLOATs](MderFLOATsandSFLOATs.html) for instructions on handling S/FLOATs and their encoding to the valueQuantity . +This profile is used to map ACOM Numeric Observations. The measured value is reported as a floating number with an optional accuracy. In GHS the value is encoded as an IEEE 11073 FLOAT that indicates both precision and the number of significant digits. The `Observation.valueQuantity.value` element is required to honor the reported precision. See [FLOATs and SFLOATs](MderFLOATsandSFLOATs.html) for instructions on handling S/FLOATs and their encoding to the valueQuantity . ### Mapping the unit code to FHIR -The MDC unit code as provided by the PHD needs to be mapped to UCUM. See [Obtaining the Unit code]({{ output }}ObtainUnitCode.html) for details on how to obtain the unit code. +The MDC unit code as provided by the PHD needs to be mapped to UCUM. See [MDC Nomenclature Codes](Nomenclaturecodes.html) for more details. <style>table, th, td { border: 1px solid black; diff --git a/input/intro-notes/StructureDefinition-PhgDevice-notes.md b/input/intro-notes/StructureDefinition-PhgDevice-notes.md index 575fa73..5b9da61 100644 --- a/input/intro-notes/StructureDefinition-PhgDevice-notes.md +++ b/input/intro-notes/StructureDefinition-PhgDevice-notes.md @@ -9,7 +9,7 @@ PHGs are required to have a system identifier. This identifier follows the same The PHG `Device.type` is given by the MDC code 531981. The reference identifier for this code is `MDC_MOC_VMS_MDS_AHD`. "AHD" stands for Application Hosting Device and is the name Continua gave to what is commonly known as a PHG. #### **Time synchronization** -The time synchronization is mapped to a device property element with as type the MDC code 68220. The possible codes for the time synchronization method come from the [MDC Time Synchronization Methods value set](ValueSet-MDCTimeSyncMethodCodes.html). +The time synchronization is mapped to a device property element with as type the MDC code 68220. The possible codes for the time synchronization method come from the [MDC Time Synchronization Methods value set](ValueSet-MDCTimeSyncMethods.html). #### **Remaining Optional Data** The treatment of further optional information in a mock SystemInfo object is similar as in the Phd Device Profile. @@ -39,12 +39,12 @@ The PHG product information is reported in the same way as in the Phd Device Pro ##### **Continua Certified PHD interfaces** -The list of Continua Certified PHD interfaces can be provided by PHGs based on the IEEE 11073-20601 standard. It is not supported by the IEEE 11073-10206 ACOM standard. It is the complement of the same attribute in the Phd Device Profile and encoded in `property` elements in the same way. +The list of Continua Certified PHD interfaces can be provided by older PHGs based on the IEEE 11073-20601 standard. It is not supported by the IEEE 11073-10206 ACOM standard. It is the complement of the same attribute in the Phd Device Profile and encoded in `property` elements in the same way. ##### **Continua Certified Health & Fitness interfaces** -The list of Continua Certified PHD interfaces can be provided by PHGs based on the IEEE 11073-20601 standard. It is not supported by the IEEE 11073-10206 ACOM standard. +The list of Continua Certified PHD interfaces can be provided by older PHGs based on the IEEE 11073-20601 standard. It is not supported by the IEEE 11073-10206 ACOM standard. -The Health and Fitness codes are mapped to a list of `property` elements. The codes are from the [MDC Health and Fitness Codes value set](ValueSet-MDCHealthFitnessCodes.html). +The Health and Fitness codes are mapped to a list of `property` elements. The codes are from the [MDC Health and Fitness Codes value set](ValueSet-ContinuaPHGInterfaces.html). ##### **Regulation Status** The PHG regulation status is reported in the same way as in the Phd Device Profile. diff --git a/input/pagecontent/CodeableConcepts.md b/input/pagecontent/CodeableConcepts.md deleted file mode 100644 index f273900..0000000 --- a/input/pagecontent/CodeableConcepts.md +++ /dev/null @@ -1,11 +0,0 @@ -In this guide there will be several instances where the IEEE 11073-10101 nomenclature (MDC) codes are mapped to FHIR. In almost all cases this mapping involves an element that is a `CodeableConcepts` data type. The mapping is as follows: - - - `CodeableConcept.coding.code` = MDC code (decimal value) - - `CodeableConcept.coding.system` = urn:iso:std:iso:11073:10101 - - `CodeableConcept.display` = reference identifier (*optional*) - -The reference identifier in the `display` element is optional since the uploader may not know what the code means; for example, if the uploader works with a PHD specialization developed after the uploader had been released. However, this guide encourages that the `display` element contains at least the reference identifier for the MDC code if it is known. - -The `display` element itself is also optional for future compatibility. Any `display` element entry requires that the uploader have previous knowledge of the code as display information is not provided by protocol. - -The `text` element can also used to provide additional information about the used code. An option is that the `text` element is populated with the reference identifier followed by additional implementation-defined text describing the code which may be in the local language. For example, `"MDC_CTXT_GLU_MEAL: Meal associated with measurement"`. diff --git a/input/pagecontent/DIMtoFHIRMapping.md b/input/pagecontent/DIMtoFHIRMapping.md index a1a934f..053ad16 100644 --- a/input/pagecontent/DIMtoFHIRMapping.md +++ b/input/pagecontent/DIMtoFHIRMapping.md @@ -83,7 +83,7 @@ The simplest example of a mapping of a discrete observation, where the measureme This mapping applies to simple types of PHD measurements whose value is given by a finite list of codes, for example the pulsatile characteristics measurement of a pulse oximeter or the meal context associated with a glucose measurement. In the pulse oximeter case there are three codes defined that can be reported; trigger on a beat, trigger on a maximum inrush, and no pulsatile event occurred. The latter is only reported by the device in special conditions and is usually not reported. This implementation guide specifies a structure definition profile that applies to all discrete observation that report a single code. ### Multiple Boolean Observation Mapping Example -The Multiple Boolean Observation or bit string Observation is the most difficult measurement class to map because HL7 does not support this measurement type. The reported value is a bit string where each bit can mean something. This type of measurement is typically used to report events, statuses, or conditions when more than one of these situations can happen at the same time. They are classed as either events or states. To map this measurement to FHIR the BITs integer needs to be converted to codes. This IG contains a code system for this purpose allowing one to map a BITs value to a set of valueCodeableConcepts. For details about the code system and links to the code system itself see [ASN1 To HL7 CodeSystem](CodeSystem-ASN1ToHL7.html). The code system has a code and a definition per bit. Each bit is mapped to an `Observation.component` with one of these codes. +The Multiple Boolean Observation or bit string Observation is the most difficult measurement class to map because HL7 does not support this measurement type. The reported value is a bit string where each bit can means something. This type of measurement is typically used to report events, statuses, or conditions when more than one of these situations can happen at the same time. They are classed as either events or states. To map this measurement to FHIR the BITs integer needs to be converted to codes. This IG contains a code system for this purpose allowing one to map a BITs value to a set of valueCodeableConcept components. For details about the code system and links to the code system itself see [ASN1 To HL7 CodeSystem](CodeSystem-ASN1ToHL7.html). The code system has a code and a definition per bit. Each bit is mapped to an `Observation.component` with one of these codes. The simplest example of a mapping of an ASN1 BITs enumeration object to a FHIR Observation resource is as follows: diff --git a/input/pagecontent/DIMtoFHIRMappingDetails.md b/input/pagecontent/DIMtoFHIRMappingDetails.md deleted file mode 100644 index a5d550f..0000000 --- a/input/pagecontent/DIMtoFHIRMappingDetails.md +++ /dev/null @@ -1,14 +0,0 @@ -In this section the details of the mapping of the IEEE 11073-20601 Metric objects to FHIR resources are discussed. - - - [Definition of a Metric Measurement]({{ output }}DefinitionMetricMsmt.html) - - [Protocol Only Metric Attributes]({{ output }}MetricAttributesofNoInterest.html) - - [Mder FLOATs and SFLOATs]({{ output }}MderFLOATsandSFLOATs.html) - - [Nomenclature Codes]({{ output }}Nomenclaturecodes.html) - - [FHIR’s Codeable Concepts]({{ output }}CodeableConcepts.html) - - [Obtaining the Observation.code]({{ output }}ObtainObservationCode.html) - - [Obtaining the Unit code]({{ output }}ObtainUnitCode.html) - - [ASN1 BITS Code System]({{ output }}CodeSystem-ASN1ToHL7.html) - - [Generating the Timestamp part of the Observation Identifier]({{ output }}GeneratingtheTimeStampPartIdentifier.html) - - - \ No newline at end of file diff --git a/input/pagecontent/DefinitionMetricMsmt.md b/input/pagecontent/DefinitionMetricMsmt.md deleted file mode 100644 index 915361c..0000000 --- a/input/pagecontent/DefinitionMetricMsmt.md +++ /dev/null @@ -1,45 +0,0 @@ -The IEEE 11073-20601 protocol is not only extensible but self-describing. The PHG does not need to know, in advance, anything about the type of measurements the PHD supports. All this information is provided in the protocol exchanges. That exchange may involve the sending of data that is not a measurement. For example the user may change the units on a weight scale from pounds to kilograms while associated with a PHG. The scale will inform the PHG of this change. If that change is sent without an accompanying weight, the incidence of the change alone makes no sense to send downstream. Consequently, a measurement is only reported if the PHD sends one of twelve attributes in the metric event (called an Observation Scan in IEEE 11073-20601 language). These attributes are: - -<style>table, th, td { -border: 1px solid black; -border-collapse:collapse; -padding: 6px;}</style> - -|Measurement Attribute|Description| -|---|---| -|Basic-Nu-Observed-Value|Contains a single number encoded as an Mder SFLOAT\*| -|Simple-Nu-Observed-Value|Contains a single number encoded as a Mder FLOAT\*| -|Compound-Basic-Nu-Observed-Value|Contains multiple numbers encoded as Mder SFLOATs\*| -|Compound-Simple-Nu-Observed-Value|Contains multiple numbers encoded as Mder FLOATs\*| -|Nu-Observed-Value|Contains single number encoded as an Mder FLOAT\* along with units and type data| -|Compound Nu-Observed-Value|Contains multiple numbers encoded as an Mder FLOATs\* with units and type data| -|Simple-Sa-Observed-Value|Contains a sequence of scaled periodic numeric values| -|Enum-Observed-Value-Simple-OID|Contains a measurement that is an MDC code| -|Enum-Observed-Value-Basic-Bit-Str|Contains a measurement that is an ASN1 BITs string in 16-bits| -|Enum-Observed-Value-Simple-Bit-Str|Contains a measurement that is an ASN1 BITs string in 32-bits| -|Enum-Observed-Value-Simple-Str|Contains a measurement that is human-readable string (rare)| -|Enum-Observed-Value|Contains a measurement that is a 32-bit ASN1 BITs, MDC code, or String plus type data| - -\*Mder Floats are described [here](MderFLOATsandSFLOATs.html) - -A metric *measurement* always contains one and only one of the above attributes. If a metric event is sent by the PHD that does NOT contain one of the 12 measurement attributes, the metric event is providing information so the PHG can decode any subsequently sent measurements. - -However, some of the attributes represent the same type of measurement such as the Basic-Nu-Observed-Value and Simple-Nu-Observed-Value. The only difference between the two is one of them uses 16 bits (Mder SFLOAT) to represent the measurement and the other 32 bits (Mder FLOAT). That difference is solely for protocol efficiency. In the end, these 12 measurement attributes reduce to 6 different measurement types - - - a single number (Basic-, Simple-, and Nu-Observed-Value) - - a vector (Compound-*-Nu-Observed-Value) - - a sequence of periodic data (Simple-Sa-Observed-Value) - - a code (Enum-Observed-Value-Simple-OID) - - a set of binary states or events (Enum-Observed-Value-*-Bit-Str) - - a human readable string (Enum-Observed-Value-Simple-Str) - - resulting in the 6 measurement profiles described in this guide. The Enum-Observed-Value can be any one of a code, set of binary events, or a human readable string depending upon parameters. - -Again, these details are only of concern to the *encoder* of the FHIR resources, the *consumer* of the FHIR resources is not concerned with the types of attributes delivered by the PHD. - - - - - - - diff --git a/input/pagecontent/MderFLOATsandSFLOATs.md b/input/pagecontent/MderFLOATsandSFLOATs.md index 01182cf..b3fb13a 100644 --- a/input/pagecontent/MderFLOATsandSFLOATs.md +++ b/input/pagecontent/MderFLOATsandSFLOATs.md @@ -1,4 +1,4 @@ -Mder FLOATs and SFLOATs are the IEEE 11073 means of encoding floating point numbers. The primary reason for this encoding is to indicate the precision of the measurement. The FLOAT is 32-bits and the SFLOAT is 16-bits. In the FLOAT, the most significant byte is the exponent and the remaining 24 bits the mantissa. Both the exponent and mantissa are signed. In the SFLOAT, the most significant 4 bits is the exponent and the remaining 12 bits the mantissa. +IEEE 11073 uses ASN.1 MDER (Medical Device Encoding Rules) to encode floating point numbers in FLOAT or SFLOAT structures. The primary reason for this encoding is to indicate the precision of the measurement. The FLOAT is 32-bits and the SFLOAT is 16-bits. In the FLOAT, the most significant byte is the exponent and the remaining 24 bits the mantissa. Both the exponent and mantissa are signed. In the SFLOAT, the most significant 4 bits is the exponent and the remaining 12 bits the mantissa. The exponent gives the precision. It indicates where the decimal point goes in the mantissa. A negative exponent of -*N* moves the decimal point to the left *N* places and a positive exponent of +*N* moves the decimal point to the right *N* places. diff --git a/input/pagecontent/MetricAttributesofNoInterest.md b/input/pagecontent/MetricAttributesofNoInterest.md deleted file mode 100644 index 43c445e..0000000 --- a/input/pagecontent/MetricAttributesofNoInterest.md +++ /dev/null @@ -1,29 +0,0 @@ -Protocol-Only attributes are **not** mapped to FHIR. - -In the IEEE 11073-20601 specification, measurements are mapped to Metric Objects. The Metric Object contains several attributes that are used to describe the measurement such as the Type, Unit-Code, and Simple-Nu-Observed-Value. However, it also contains attributes that are only of interest to the PHG for the purposes of decoding the measurement. For the purposes of optimization on the wire, the PHD only sends attributes that have changed when it sends a measurement. The PHG is expected to retain static and dynamic information. There are also techniques used to efficiently encode the data and tell the PHG how big and in what sense this data may come. To accomplish this encoding the PHD sends keys describing the encoding and the PHG uses these keys to decode the data. These keys are not meant for security purposes but just to minimize data transmission size. - -Attributes are also used for these keys. Once the measurement has been reconstructed using these keys and the retained static and dynamic data, the attributes providing these keys are no longer of interest. This guide will refer to these attributes as 'Protocol-Only' attributes. - -<style>table, th, td { -border: 1px solid black; -border-collapse:collapse; -padding: 6px;}</style> - -|Protocol-Only Attribute|Description| -|- -|Handle|Provides the PHG with a key to access the static and dynamic information associated with this metric| -|Metric-Spec-Small|Gives info about the delivery and nature of the metric events| -|Attribute-Value-Map|Provides a means to compact attribute values| -|Metric-Structure-Small|Gives info about the number of entries in compound attributes| -|Capability-Mask-Basic|Indicates which of the 16-bit ASN1 BITs are supported by PHD| -|Capability-Mask-Simple|Indicates which of the 32-bit ASN1 BITs are supported by PHD| -|State-Flag-Basic|Indicates whether the 16-bit ASN1 BITs are a 'state' or an 'event'| -|State-Flag-Simple|Indicates whether the 32-bit ASN1 BITs are a 'state' or an 'event'| - -The last four attributes are essential for the decoder to properly map ASN1 BITS measurements to FHIR using the ASN1 coding system but the attributes themselves are not of interest once mapped. For example, the Capability-Mask-* attribute tells which bits are supported by the PHD. The encoder needs to know which bits these are but once known, the attribute value itself is no longer of interest. The State-Flag-* indicates to the decoder whether the bit is an event or a state. If an event, only the set case (event occurred) needs to be recorded, for example, 'sensor malfunctioned' in the sensor status measurement of several specializations. If a 'state' both the set or cleared case needs to be reported, for example 'patient in room' or 'patient not in room' in the independent living case. - - - - - - diff --git a/input/pagecontent/Nomenclaturecodes.md b/input/pagecontent/Nomenclaturecodes.md index 0eb9ebc..dda601c 100644 --- a/input/pagecontent/Nomenclaturecodes.md +++ b/input/pagecontent/Nomenclaturecodes.md @@ -4,9 +4,42 @@ Associated with each 32-bit code is a reference identifier. The reference identi In FHIR, the 32-bit value of the code is always used. If in the PHD to PHG exchange sometimes a 16-bit code is used when the partition can be inferred from the attribute to decrease bandwidth. In these situations the encoder must convert the 16-bit value to the appropriate 32-bit value. -In IEEE 11073-10101 Units are also encoded as nomenclature codes. HL7 and IHE favor the use of UCUM for units. This guide requires IEEE 11073-10101 nomenclature codes for units to be mapped to the equivalent UCUM code. To maintain future compatibility, the use of the MDC nomenclature code is allowed if a UCUM code for the MDC term did not exist, or was not used by PHD standards, at the time the encoder was written. - The set of nomenclature codes is extensive, but it is segmented by partitions. Many of the codes used in the PHD measurement types and measurement values (when codes) come from the SCADA, INFRA, SITES, PHD_DM, PHD_HF, and PHD_AI partitions. This guide does not restrict the codes to come from only those partitions for future compatibility reasons. New partitions could be added and those codes could be used in future PHD specializations. Since the codes are provided by the PHD, the uploader does not need to maintain a code dictionary unless it wants to include the reference identifier or display text about the code. If this guide were to restrict the allowable codes to a given set of partitions, that restriction would prevent an older implementation from working with future devices when it otherwise could have worked with the device. It is clear, however, that any consumer and interpreter of the uploaded information *would* need to know about the new codes. -More information describing the MDC coding system can be found [here](https://terminology.hl7.org/MDC.html) +#### Unit codes +IEEE 11073-10206 ACOM unit codes are MDC codes from partition 4 of IEEE 11073-10101. HL7 and IHE favor the use of UCUM for units. This guide requires IEEE 11073-10101 nomenclature codes for units to be mapped to the equivalent UCUM code. A mapping can be found in the [RTMMS](https://rtmms.nist.gov/) and in the latest version of IEEE 11073-10101. + +If the rare situation arises where a new unit has been introduced or the PHD uses a unit code that has not been previously used in PHD specializations, the FHIR encoder may use the MDC code in place of the UCUM code. This allows the encoder to work with future PHDs without requiring an update to the encoder. + +#### Mapping to FHIR +The IEEE 11073-10101 nomenclature codes are mapped to FHIR using the `CodeableConcept` data type. The mapping is as follows: + - `CodeableConcept.coding.code` = MDC code (decimal value) + - `CodeableConcept.coding.system` = urn:iso:std:iso:11073:10101 + - `CodeableConcept.coding.display` = reference identifier (*optional*) + - `CodeableConcept.text` = additional information about the code (*optional*) + +The reference identifier in the `display` element is optional since the uploader may not know what the code means; for example, if the uploader works with a PHD specialization developed after the uploader had been released. However, this guide encourages that the `display` element contains at least the reference identifier for the MDC code if it is known. + +The `display` element itself is also optional for future compatibility. Any `display` element entry requires that the uploader have previous knowledge of the code as display information is not provided by protocol. + +The `text` element can also used to provide additional information about the used code. An option is that the `text` element is populated with the reference identifier followed by additional implementation-defined text describing the code which may be in the local language. For example, `"MDC_CTXT_GLU_MEAL: Meal associated with measurement"`. + +#### Observation codes +Every IEEE 11073-10206 ACOM Observation instance is required to have a Type attribute. The Type attribute value is an MDC term code that maps directly to the `Observation.code` element which is a `CodeableConcept`. +This means, following the mapping above, that the `Observation.code` element is populated as follows: + * `Observation.code.coding.code` = *code value* + * `Observation.code.coding.system` = "urn:iso:std:iso:11073:10101" + * `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 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, + * any other codings may be placed in an additional coding element. + +PHGs operating in certain realms may be required to provide translations to a realm-specified coding system. For example, in the United States realm, LOINC is preferred. [RTMMS](https://rtmms.nist.gov/) contains a mapping to LOINC for a subset of the MDC codes. + +#### Additional information +More information describing the use of the MDC coding system in HL7 standards can be found [here](https://terminology.hl7.org/MDC.html) diff --git a/input/pagecontent/ObtainObservationCode.md b/input/pagecontent/ObtainObservationCode.md index 0f41635..f5cdf5c 100644 --- a/input/pagecontent/ObtainObservationCode.md +++ b/input/pagecontent/ObtainObservationCode.md @@ -1,19 +1,19 @@ Every IEEE 11073-10206 ACOM Observation instance is required to have a Type attribute. The Type attribute value is an MDC term code that maps directly to the `Observation.code` element. The `Observation.code` element is populated as follows: -* if the application wishes to transcode this MDC code into other coding systems the application is free to do so but - * the MDC code shall be present in a coding element - * if the code matches one of the [FHIR observation-vitalsigns codes]({{ site.data.fhir.path }}observation-vitalsigns.html), the observation-vitalsigns code shall be present in a coding element - * any other coding translations desired may be placed in an additional coding element. -* for the MDC code the mapping is as follows: +* If the application wishes to transcode this MDC code into other coding systems the application is free to do so but: + * the MDC code shall be present in a coding element, + * if the code matches one of the [FHIR observation-vitalsigns codes]({{ site.data.fhir.path }}observation-vitalsigns.html), the observation-vitalsigns LOINC code shall be present in a coding element, + * any other codings may be placed in an additional coding element. +* For the MDC code the mapping is as follows: * `Observation.code.coding.code` = *value* * `Observation.code.coding.system` = "urn:iso:std:iso:11073:10101" - * `Observation.code.display` should contain the reference identifier - * `Observation.code.text` should contain the reference identifier as part of the text followed by a localized description of the measurement type + * `Observation.code.coding.display` optional, should contain the reference identifier + * `Observation.code.text` optional, could contain the reference identifier followed by a localized description of the measurement type. The requirement for the MDC reference identifier is not mandatory and is not used as the `Observation.code.coding.code` value because the reference identifier is not provided by the sensor device in the exchange protocol. Requiring the reference identifier would require that the PHG have an internal map. However, the main reason for not requiring the reference identifier is that doing so would defeat future interoperability. An older PHG would not know the reference identifier of a new specialization but it would be able to propagate the new code since that is provided by the device. -The MDC code entry is required, but the concept may be expressed in additional coding systems as well. The choice of any additional codings is up to the application. PHGs operating in certain realms may be required to provide translations to a realm-specified coding system. For example, in the United States realm, LOINC is strongly preferred. [RTMMS](https://rtmms.nist.gov/) contains a mapping for a subset of the MDC codes. +The MDC code entry is required, but the concept may be expressed in additional coding systems as well. The choice of any additional codings is up to the application. PHGs operating in certain realms may be required to provide translations to a realm-specified coding system. For example, in the United States realm, LOINC is preferred. [RTMMS](https://rtmms.nist.gov/) contains a mapping for a subset of the MDC codes. The consumer of FHIR resources containing the PHD data does not need to concern itself with this complexity. All it needs to do is obtain the `Observation.code.coding.code` element supporting the 11073-10101 system value to get the measurement type. diff --git a/input/pagecontent/ObtainUnitCode.md b/input/pagecontent/ObtainUnitCode.md deleted file mode 100644 index cecf401..0000000 --- a/input/pagecontent/ObtainUnitCode.md +++ /dev/null @@ -1,8 +0,0 @@ -Observations and Observation Components that report quantities (Numerics and Sample Arrays) have units. - -Obtaining the unit in most cases is as simple as decoding the Unit-Code attribute. - -IEEE 11073-10206 ACOM unit codes are MDC values from partition 4 of IEEE 11073-10101. The FHIR encoder need to map these codes to the appropriate UCUM codes. -A mapping can be found in the [RTMMS](https://rtmms.nist.gov/) and in the latest version of IEEE 11073-10101. - -In case the rare situation arises where a new unit has been introduced or the PHD uses a unit code that has not been previously used in PHD specializations, the FHIR encoder may use the MDC code in place of the UCUM code. diff --git a/input/pagecontent/ProfileConsumers.md b/input/pagecontent/ProfileConsumers.md index 6911226..c2bf8b6 100644 --- a/input/pagecontent/ProfileConsumers.md +++ b/input/pagecontent/ProfileConsumers.md @@ -120,7 +120,7 @@ PHDs can send measurements that have additional descriptive information. An exam More details on the extensions that can be used with quantities can be found in the [PhdNumericObservation profile](StructureDefinition-PhdNumericObservation.html). ##### Supplemental Types -Supplemental type information is indicated by the `Observation.code` element having the value 68193. The value type of a supplemental type entry is always a CodeableConcept and is therefore given by Observation.component.valueCodeableConcept.coding.code. There may be more than one `Observation.component` entry containing supplemental type information. An example of a supplemental types component entry is as follows: +Supplemental type information is indicated by the `Observation.code` element having the value 68193. The value type of a supplemental type entry is always a CodeableConcept and is therefore given by `Observation.component.valueCodeableConcept.coding.code`. There may be more than one `Observation.component` entry containing supplemental type information. An example of a supplemental types component entry is as follows: {% fragment Observation/numeric-spotnumeric JSON EXCEPT:component[0] %} @@ -163,7 +163,7 @@ When there is no special value the `Observation.valueQuantity` is populated with |`Observation.valueQuantity.code`|units in UCUM| |`Observation.valueQuantity.system="http://unitsofmeasure.org"`|code system is UCUM| -If a special value is reported an `Observation.dataAbsentReason` replaces the valueQuantity. The dataAbsentReason is a CodeableConcept and will have the following possible codes from the data absent reason coding system "http://terminology.hl7.org/CodeSystem/data-absent-reason": +If a special value is reported an `Observation.dataAbsentReason` then this replaces the valueQuantity. The dataAbsentReason is a CodeableConcept and will have the following possible codes from the data absent reason coding system "http://terminology.hl7.org/CodeSystem/data-absent-reason": - `Observation.dataAbsentReason.coding.code="not-a-number"` - `Observation.dataAbsentReason.coding.code="positive-infinity"` @@ -174,8 +174,6 @@ The `Observation.system` in the above cases is always - `Observation.dataAbsentReason.coding.system="http://terminology.hl7.org/CodeSystem/data-absent-reason"` -IEEE 11073-20601 defines two other special values that are not translated to FHIR which are encoded as "error". To date, there has been no market PHD which reports the other two special values. - An example of the valueQuantity in the Phd Numeric Observation Profile for a thermometer reporting a value in °C is as follows: {% fragment Observation/temperature-observation JSON EXCEPT:valueQuantity %} @@ -217,7 +215,7 @@ and the individual `Observation.component` entries describing each compound entr {% fragment Observation/compound-numeric-blood-pressure-no-mean JSON EXCEPT:component %} -The Phd Compound Numeric Profile can contain additional entries as noted in the [Additional Descriptive Data](#additional-descriptive-data) section above. However, the codes of all `Observation.component` entries that are part of a compound measurement will always have an MDC entry (not ASN1ToHL7) and the MDC entry will ***never*** have a partition value (the upper 16 bits) equal to 1. +The Phd Compound Numeric Profile can contain additional entries as noted in the [Additional Descriptive Data](#additional-descriptive-data) section above. However, the codes of all `Observation.component` entries that are part of a compound measurement will always have an MDC code and not a code from the ASN1ToHL7 code system. #### Remark on compound observations The decision to report a compound observation versus independent observations is made by the designers of the IEEE PHD device specialization standards. The IEEE PHD and FHIR policies to choose between these options are similar. This IG maps an ACOM compound observation to a FHIR Observation resource with multiple components. @@ -258,7 +256,7 @@ Each `Observation.component` entry will have the following: The 'independent living' example mentioned above does not currently exist in any specialization but it is illustrative of the concept. However, a pulse oximeter device sensor status measurement containing several different events does exist. An example of such a measurement can be found [here](Observation-bits-observation.html) -All of the entries are events in this example so the values are always "Y" indicating the event occurred. One might note that the ANS1ToHL7 code 150604.*x* in all cases contains the MDC code of the measurement 150604. That relationship will always be true for all event and state measurement value types. In addition, the MDC code of the overall measurement will never have a partition (the upper 16 bits) value of 1. +All of the entries are events in this example so the values are always `true` indicating the event occurred. One might note that the ANS1ToHL7 code 150604.*x* in all cases contains the MDC code of the measurement 150604. That relationship will always be true for all event and state measurement value types. ### Periodic measurements Periodic measurements are typically waveforms like ECG traces and are a sequence of scalars. diff --git a/input/pagecontent/TechnicalImplementationGuidance.md b/input/pagecontent/TechnicalImplementationGuidance.md index 730d633..4e06dfb 100644 --- a/input/pagecontent/TechnicalImplementationGuidance.md +++ b/input/pagecontent/TechnicalImplementationGuidance.md @@ -4,15 +4,9 @@ The mapping sections require knowledge of the IEEE 11073-10206 model and are int - [Remote Patient Monitoring Considerations](RemotePatientMonitoringConsiderations.html) - [Generic and Extensible Modelling Approach](GenericModel.html) - - [DIM to FHIR Mapping Basics](DIMtoFHIRMapping.html) - - [DIM to FHIR Mapping Details](DIMtoFHIRMappingDetails.html) - - [Definition of a Metric Measurement](DefinitionMetricMsmt.html) - - [Protocol Only Metric Attributes](MetricAttributesofNoInterest.html) - - [Mder FLOATs and SFLOATs](MderFLOATsandSFLOATs.html) - - [Nomenclature Codes](Nomenclaturecodes.html) - - [FHIR's Codeable Concepts](CodeableConcepts.html) - - [Obtaining the Observation.code](ObtainObservationCode.html) - - [Obtaining the Unit code](ObtainUnitCode.html) + - [DIM to FHIR Mapping](DIMtoFHIRMapping.html) + - [IEEE 11073 FLOATs and SFLOATs](MderFLOATsandSFLOATs.html) + - [IEEE 11073-10101 Nomenclature Codes](Nomenclaturecodes.html) - [Generating the Timestamp part of the Observation Identifier](GeneratingtheTimeStampPartIdentifier.html) - [Coincident Timestamp](CoincidentTimeStamp.html) - [Non-IEEE 11073-10206 PHD Devices](Non11073PHDDevices.html) diff --git a/input/resources/ACME_Inc_PrivateMDCCodes.json b/input/resources/ACME_Inc_PrivateMDCCodes.json index 9ca84bc..35764fa 100644 --- a/input/resources/ACME_Inc_PrivateMDCCodes.json +++ b/input/resources/ACME_Inc_PrivateMDCCodes.json @@ -13,7 +13,7 @@ "identifier": [ { "system": "urn:ietf:rfc:3986", - "value": "urn:oid:1.2.3.4.5.6.7.8.9.10" + "value": "urn:oid:2.999.1.2.3.4.5.6.7.8.9.10" } ], "property": [ From e7f19b1625b9989e741676dd35e442f23ebc6ed1 Mon Sep 17 00:00:00 2001 From: Erik Moll <erik.moll@philips.com> Date: Mon, 21 Jul 2025 14:04:46 +0200 Subject: [PATCH 08/10] commented out lines removed --- input/fsh/CodeSYstem.SimpleAlertOperationalStates.fsh | 1 - input/fsh/CodeSystem.ASN1ToHL7.fsh | 1 - input/fsh/CodeSystem.ContinuaDeviceIdentifiers.fsh | 1 - input/fsh/CodeSystem.ContinuaHFS.fsh | 1 - input/fsh/CodeSystem.ContinuaPHDCS.fsh | 1 - input/fsh/CodeSystem.PhdObservationCategories.fsh | 1 - 6 files changed, 6 deletions(-) diff --git a/input/fsh/CodeSYstem.SimpleAlertOperationalStates.fsh b/input/fsh/CodeSYstem.SimpleAlertOperationalStates.fsh index 6397fb2..c4aa16f 100644 --- a/input/fsh/CodeSYstem.SimpleAlertOperationalStates.fsh +++ b/input/fsh/CodeSYstem.SimpleAlertOperationalStates.fsh @@ -6,7 +6,6 @@ Description: "The operational states for the simple alerting system." * ^experimental = false * ^publisher = "Health Level Seven International (Devices Work Group)" * ^caseSensitive = true -// * ^hierarchyMeaning = #grouped-by * ^content = #complete * #Limits-On "Limits On" "The alert system is checking the high and low limits." * #Limits-Off "Limits Off" "The alert system is not checking the high and low limits." diff --git a/input/fsh/CodeSystem.ASN1ToHL7.fsh b/input/fsh/CodeSystem.ASN1ToHL7.fsh index c824860..d0e6966 100644 --- a/input/fsh/CodeSystem.ASN1ToHL7.fsh +++ b/input/fsh/CodeSystem.ASN1ToHL7.fsh @@ -19,7 +19,6 @@ Description: "CodeSystem for mapping IEEE 11073-10206 bitstrings to FHIR Codeabl * ^date = "2018-09-18" * ^publisher = "Health Level Seven International (Devices Work Group)" * ^caseSensitive = true -// * ^hierarchyMeaning = #grouped-by * ^content = #complete * ^property[0].code = #eventOrState * ^property[=].uri = "http://hl7.org/fhir/uv/phd/CodeSystem/ASN1ToHL7#eventOrState" diff --git a/input/fsh/CodeSystem.ContinuaDeviceIdentifiers.fsh b/input/fsh/CodeSystem.ContinuaDeviceIdentifiers.fsh index 1bad387..ef4adb4 100644 --- a/input/fsh/CodeSystem.ContinuaDeviceIdentifiers.fsh +++ b/input/fsh/CodeSystem.ContinuaDeviceIdentifiers.fsh @@ -12,7 +12,6 @@ Description: "Codes used to describe the Device (PHD or PHG) Identifiers, such a * ^date = "2018-11-25" * ^publisher = "Health Level Seven International (Devices Work Group)" * ^caseSensitive = true -// * ^hierarchyMeaning = #grouped-by * ^content = #complete * #SYSID "IEEE 11073 System Identifier" "This code indicates that the identifier is the IEEE 11073 SystemId from the equivalent of the System-Id attribute" * #BTMAC "Bluetooth MAC address" "This code indicates that the identifier is the Bluetooth MAC address, either classic or low energy" diff --git a/input/fsh/CodeSystem.ContinuaHFS.fsh b/input/fsh/CodeSystem.ContinuaHFS.fsh index 1b73c34..95c4020 100644 --- a/input/fsh/CodeSystem.ContinuaHFS.fsh +++ b/input/fsh/CodeSystem.ContinuaHFS.fsh @@ -10,7 +10,6 @@ Description: "Codes used to describe the Continua Health and Fitness interfaces * ^date = "2018-09-18" * ^publisher = "Health Level Seven International (Devices Work Group)" * ^caseSensitive = true -// * ^hierarchyMeaning = #grouped-by * ^content = #complete * #0 "observation-upload-soap" "The PHG has been certified for the PCD-01 upload using Web services" * #1 "consent-enabled-soap" "The PHG has been certified for the PCD-01 upload using Web services with patient consent" diff --git a/input/fsh/CodeSystem.ContinuaPHDCS.fsh b/input/fsh/CodeSystem.ContinuaPHDCS.fsh index 6f55de4..932aa29 100644 --- a/input/fsh/CodeSystem.ContinuaPHDCS.fsh +++ b/input/fsh/CodeSystem.ContinuaPHDCS.fsh @@ -10,7 +10,6 @@ Description: "Codes used to describe the PHD types and interfaces supported by a * ^date = "2018-11-24" * ^publisher = "Health Level Seven International (Devices Work Group)" * ^caseSensitive = true -// * ^hierarchyMeaning = #grouped-by * ^content = #complete * #4 "Pulse Oximeter certified" "The PHG has been certified for the Pulse Oximeter" * #6 "ECG certified" "The PHG has been certified for the minimal ECG" diff --git a/input/fsh/CodeSystem.PhdObservationCategories.fsh b/input/fsh/CodeSystem.PhdObservationCategories.fsh index 0bc7d3b..20fc6ca 100644 --- a/input/fsh/CodeSystem.PhdObservationCategories.fsh +++ b/input/fsh/CodeSystem.PhdObservationCategories.fsh @@ -10,7 +10,6 @@ Description: "Codes used for tagging observations coming from PHD devices. More * ^date = "2024-04-18" * ^publisher = "Health Level Seven International (Devices Work Group)" * ^caseSensitive = true -// * ^hierarchyMeaning = #grouped-by * ^content = #complete * #phd "PHD generated Observation" "An observation coming from a personal health device, either directly or via a personal health gateway that maps the data received from the PHD into a FHIR Observation resource." From cab082253a9732840bf850b012a2d3765e03e253 Mon Sep 17 00:00:00 2001 From: Erik Moll <erik.moll@philips.com> Date: Mon, 21 Jul 2025 14:45:03 +0200 Subject: [PATCH 09/10] cleanup DAR slicing comments --- ...efinition.PhdCoincidentTimeStampObservation.fsh | 11 ----------- ...ureDefinition.PhdCompoundNumericObservation.fsh | 12 +++--------- .../StructureDefinition.PhdCompoundObservation.fsh | 14 ++++---------- 3 files changed, 7 insertions(+), 30 deletions(-) diff --git a/input/fsh/StructureDefinition.PhdCoincidentTimeStampObservation.fsh b/input/fsh/StructureDefinition.PhdCoincidentTimeStampObservation.fsh index a6fe20e..e0241da 100644 --- a/input/fsh/StructureDefinition.PhdCoincidentTimeStampObservation.fsh +++ b/input/fsh/StructureDefinition.PhdCoincidentTimeStampObservation.fsh @@ -40,17 +40,6 @@ Description: "Observations containing a coincident timestamp." * ^definition = "This element is populated when the PHD has a time fault and the current time of the PHD cannot be obtained." * dataAbsentReason.coding[TimeFault] = http://terminology.hl7.org/CodeSystem/data-absent-reason#unknown -// * dataAbsentReason ^short = "Populated when the PHD has a time fault" -// * dataAbsentReason ^definition = "In this profile this element indicates that the current time of the PHD for the measurements reported is not known and is unable to be obtained" -// * dataAbsentReason ^comment = "This situation arises when the PHD has a time fault, perhaps by battery change. The sensor device may have stored data with timestamps taken at a time when the clock was running but after the fault the original timeline was not able to be recovered. Thus the current timeline, if any, has an unknown relationship to the previous timeline." -// * dataAbsentReason.coding = http://terminology.hl7.org/CodeSystem/data-absent-reason#unknown -// * dataAbsentReason.coding ^slicing.discriminator.type = #value -// * dataAbsentReason.coding ^slicing.discriminator.path = "code" -// * dataAbsentReason.coding ^slicing.rules = #open -// * dataAbsentReason.coding contains FhirDefault 1..1 -// * dataAbsentReason.coding[FhirDefault].code from http://hl7.org/fhir/ValueSet/data-absent-reason (required) -// * dataAbsentReason.coding[FhirDefault].code 1.. -// * dataAbsentReason.coding[FhirDefault].code = #unknown (exactly) * component ^slicing.discriminator[0].type = #value * ^slicing.discriminator[=].path = "code" * ^slicing.rules = #open diff --git a/input/fsh/StructureDefinition.PhdCompoundNumericObservation.fsh b/input/fsh/StructureDefinition.PhdCompoundNumericObservation.fsh index 8d9c679..17c225d 100644 --- a/input/fsh/StructureDefinition.PhdCompoundNumericObservation.fsh +++ b/input/fsh/StructureDefinition.PhdCompoundNumericObservation.fsh @@ -41,15 +41,9 @@ Description: "Observations coming from a PHD where the measurement is a set of n * ^definition = "The unit code shall use the UCUM system" * code 1.. * ^definition = "The MDC code must be translated to the UCUM code." - * dataAbsentReason ^short = "Populated when a special value or status in Compound-Nu-Observed-Value indicates invalid, not unavailable, or msmt ongoing" - * ^definition = "Provides a reason why the expected value in the nth element Observation.compoundComponent.valueQuantity is missing. This could be a NaN (Not a Number), PINF (Positive infinity), NINF (Negative infinity) or the reserved and not-at-this-resolution special values. It can also be indicated by the (measurement) status field of the Compound-Nu-Observed-Value. Note that the FHIR codes for NAN are no longer 'NAN' but 'not-a-number'. Similar changes have been made for NINF and PINF." - * coding ^slicing.discriminator[0].type = #value - * ^slicing.discriminator[=].path = "code" - * ^slicing.rules = #open - * coding contains FhirDefault 1..1 - * coding[FhirDefault] - * code from $DataAbsentReason (required) - * code 1.. + * dataAbsentReason ^short = "Populated when the component reports a special FLOAT value" + * ^definition = "Provides a reason why the expected value in the nth element Observation.compoundComponent.valueQuantity is missing. This happens when the FLOAT reports a special value." + * coding from http://hl7.org/fhir/ValueSet/data-absent-reason (required) * interpretation * coding ^slicing.discriminator[0].type = #value * ^slicing.discriminator[=].path = "system" diff --git a/input/fsh/StructureDefinition.PhdCompoundObservation.fsh b/input/fsh/StructureDefinition.PhdCompoundObservation.fsh index f4ef620..a777179 100644 --- a/input/fsh/StructureDefinition.PhdCompoundObservation.fsh +++ b/input/fsh/StructureDefinition.PhdCompoundObservation.fsh @@ -58,16 +58,10 @@ Description: "Observations from a PHD where the measurement is a set of numbers * ^definition = "A series of data points which are the sampled values." * valueString ^short = "The value of the string component" * ^definition = "The value of the string component" -// * component -// * dataAbsentReason ^short = "Populated when the component value is invalid or unavailable for some reason" -// * ^definition = "Provides a reason why the expected value in the component is missing. For numeric components this could be not-a-number, negative-infinity or similar." -// * coding ^slicing.discriminator[0].type = #value -// * ^slicing.discriminator[=].path = "code" -// * ^slicing.rules = #open -// * coding contains FhirDefault 1..1 -// * coding[FhirDefault] -// * code from $DataAbsentReason (required) -// * code 1.. + * dataAbsentReason ^short = "Populated when the component is missing or invalid" + * ^definition = "Provides a reason why the expected value in the nth element component.value[x] is missing. This happens a.o. when a FLOAT component reports a special value." + * coding from http://hl7.org/fhir/ValueSet/data-absent-reason (required) + * component * extension contains http://hl7.org/fhir/uv/phd/StructureDefinition/Accuracy named Accuracy 0..1 * extension contains http://hl7.org/fhir/uv/phd/StructureDefinition/Confidence95 named Confidence95 0..1 From 5984526c46cad0c763bfb6eebdc8a284bef5301a Mon Sep 17 00:00:00 2001 From: Erik Moll <erik.moll@philips.com> Date: Tue, 22 Jul 2025 11:09:48 +0200 Subject: [PATCH 10/10] further Jira tickets - introduced device property for USB VID/PID --- .../phd-00601900010E9234.F45EABA80832.json | 15 +++++++ .../CodeSystem.ContinuaDeviceIdentifiers.fsh | 2 +- input/fsh/StructureDefinition.PhdDevice.fsh | 15 ++++++- .../StructureDefinition.SimpleAlerting.fsh | 2 +- .../intro-notes/CodeSystem-ASN1ToHL7-intro.md | 4 +- input/intro-notes/Device-phg-example-intro.md | 2 +- ...ion-PhdBITsEnumerationObservation-notes.md | 4 +- ...tureDefinition-PhdBaseObservation-notes.md | 45 ++++++++++--------- .../StructureDefinition-PhdDevice-intro.md | 20 ++++----- .../StructureDefinition-PhdDevice-notes.md | 23 ++++++---- ...eDefinition-PhdNumericObservation-notes.md | 4 +- .../StructureDefinition-PhdPatient-intro.md | 4 +- .../StructureDefinition-PhdPatient-notes.md | 19 ++++---- .../StructureDefinition-PhgDevice-intro.md | 2 +- ...tructureDefinition-SimpleAlerting-notes.md | 4 +- input/pagecontent/CoincidentTimeStamp.md | 2 +- input/pagecontent/DIMtoFHIRMapping.md | 2 +- input/pagecontent/ProfileConsumers.md | 6 +-- 18 files changed, 102 insertions(+), 73 deletions(-) diff --git a/input/examples/phd-00601900010E9234.F45EABA80832.json b/input/examples/phd-00601900010E9234.F45EABA80832.json index 68fb9c5..4507e89 100644 --- a/input/examples/phd-00601900010E9234.F45EABA80832.json +++ b/input/examples/phd-00601900010E9234.F45EABA80832.json @@ -148,6 +148,21 @@ "text": "None" } ] + }, + { + "type": { + "coding": [ + { + "system": "http://hl7.org/fhir/uv/phd/CodeSystem/ContinuaDeviceIdentifiers", + "code": "USB" + } + ] + }, + "valueCode": [ + { + "text": "VID_1234:PID_5678" + } + ] } ] } \ No newline at end of file diff --git a/input/fsh/CodeSystem.ContinuaDeviceIdentifiers.fsh b/input/fsh/CodeSystem.ContinuaDeviceIdentifiers.fsh index ef4adb4..1a2c6fa 100644 --- a/input/fsh/CodeSystem.ContinuaDeviceIdentifiers.fsh +++ b/input/fsh/CodeSystem.ContinuaDeviceIdentifiers.fsh @@ -16,5 +16,5 @@ Description: "Codes used to describe the Device (PHD or PHG) Identifiers, such a * #SYSID "IEEE 11073 System Identifier" "This code indicates that the identifier is the IEEE 11073 SystemId from the equivalent of the System-Id attribute" * #BTMAC "Bluetooth MAC address" "This code indicates that the identifier is the Bluetooth MAC address, either classic or low energy" * #ETHMAC "Ethernet MAC address" "This code indicates that the identifier is the Ethernet MAC address" -// * #USB "USB PID and VID designators" "This code indicates that the identifier is the USB Pid and Vid values" +* #USB "USB PID and VID designators" "This code indicates that the (non-unique) identifier is the USB Pid and Vid values" * #ZIGBEE "ZigBee MAC address" "This code indicates that the identifier is the ZigBee MAC address" diff --git a/input/fsh/StructureDefinition.PhdDevice.fsh b/input/fsh/StructureDefinition.PhdDevice.fsh index 4b11c39..f77252a 100644 --- a/input/fsh/StructureDefinition.PhdDevice.fsh +++ b/input/fsh/StructureDefinition.PhdDevice.fsh @@ -124,7 +124,8 @@ Description: "Profile for the Device Resource for a PHD" clockBitProperty 0..* and isRegulatedProperty 0..1 and clockResolutionProperty 0..1 and - timeSyncAccuracyProperty 0..1 // and + timeSyncAccuracyProperty 0..1 and + USB-VID-PID 0..1 // and //clockTypeProperty 0..1 and //powerSourceProperty 0..1 and @@ -192,6 +193,18 @@ Description: "Profile for the Device Resource for a PHD" * code 1.. * ^definition = "If bit is set, the device is not regulated. If cleared, the device is regulated." +* property[USB-VID-PID] ^short = "USB Vendor and Product ID" + * ^definition = "The USB Vendor and Product ID as reported by the PHD." + * type = ContinuaDeviceIdentifiers#USB + * ^short = "USB Vendor and Product ID" + * ^definition = "The USB Vendor and Product ID as reported by the PHD." + * valueQuantity ..0 + * valueCode.coding.system + * ^short = "USB Vendor and Product ID code system" + * ^definition = "The USB Vendor and Product ID naming system id is http://hl7.org/fhir/sid/usb-vid-pid, but that cannot be used here as this is not a code system in FHIR." + * valueCode.text 1..1 + * ^definition = "The USB Vendor and Product ID as reported by the PHD in the form of a coded string such as '1234:56AB'." + * ^comment = "The USB Vendor and Product ID is not a required attribute in the IEEE 11073-10206 standard but is often reported by PHDs that support USB transport." Mapping: IEEE-11073-10206-PhdDevice Id: IEEE-11073-10206-PhdDevice diff --git a/input/fsh/StructureDefinition.SimpleAlerting.fsh b/input/fsh/StructureDefinition.SimpleAlerting.fsh index 63bd5f1..a4bb299 100644 --- a/input/fsh/StructureDefinition.SimpleAlerting.fsh +++ b/input/fsh/StructureDefinition.SimpleAlerting.fsh @@ -33,7 +33,7 @@ Context: Observation, DeviceMetric, Observation.component * extension[alertOperationalText] * value[x] 0.. * value[x] only string - * valueString ^definition = "A human readable description of the operational state of the alerting system ()." + * valueString ^definition = "A human readable description of the operational state of the alerting system." * extension[thresholdNotificationText] * value[x] 0.. * value[x] only string diff --git a/input/intro-notes/CodeSystem-ASN1ToHL7-intro.md b/input/intro-notes/CodeSystem-ASN1ToHL7-intro.md index 0a0aae1..c7f87a2 100644 --- a/input/intro-notes/CodeSystem-ASN1ToHL7-intro.md +++ b/input/intro-notes/CodeSystem-ASN1ToHL7-intro.md @@ -17,6 +17,4 @@ If the ASN.1 bit represents an event, only the set condition needs to be reporte This code system is used to report IEEE 11073-10206 Multiple Boolean State observations, where each bit represents a state and for Bluetooth GHS Compound state/event observations that come with a mask to indicate per bit if it is a state or an event and whether it is supported by the device or not. -It is also used for IEEE 11073-20601 Bit-Str metrics. In version 4 or later of the IEEE 11073-20601 specification the enumeration metric object supports both a Capability-Mask-Simple/Basic and State-flag-Simple/Basic attribute that must be present when Bit-Str is reported. The Capability-Mask attribute will have a bit set when the corresponding bit in the actual measurement is supported by the device. The State-Flag attribute will have a bit set if the corresponding bit is a state. If cleared, the corresponding bit is an event. These attributes are not present in IEEE 11073-20601 versions 3 or earlier. If such version is used, the uploader will need to obtain this information from the ASN.1 mapping tables. - - +It is also used for IEEE 11073-20601 Bit-Str metrics. In version 4 or later of the IEEE 11073-20601 specification the enumeration metric object supports both a Capability-Mask-Simple/Basic and State-flag-Simple/Basic attribute that must be present when Bit-Str is reported. The Capability-Mask attribute will have a bit set when the corresponding bit in the actual measurement is supported by the device. The State-Flag attribute will have a bit set if the corresponding bit is a state. If cleared, the corresponding bit is an event. These attributes are not present in IEEE 11073-20601 versions 3 or earlier. If such version is used, the uploader will need to obtain this information from the [ASN.1 to HL7 code system](CodeSystem-ASN1ToHL7.html). diff --git a/input/intro-notes/Device-phg-example-intro.md b/input/intro-notes/Device-phg-example-intro.md index f48967c..8817253 100644 --- a/input/intro-notes/Device-phg-example-intro.md +++ b/input/intro-notes/Device-phg-example-intro.md @@ -1 +1 @@ -This example shows the mapping of an Android gateway to the Device resource. \ No newline at end of file +This example shows a Device resource for an Android gateway. \ No newline at end of file diff --git a/input/intro-notes/StructureDefinition-PhdBITsEnumerationObservation-notes.md b/input/intro-notes/StructureDefinition-PhdBITsEnumerationObservation-notes.md index d621cd1..5cebd1b 100644 --- a/input/intro-notes/StructureDefinition-PhdBITsEnumerationObservation-notes.md +++ b/input/intro-notes/StructureDefinition-PhdBITsEnumerationObservation-notes.md @@ -1,7 +1,7 @@ -The fololwing section gives more details on the mapping of BITS to a FHIR Observation resource. +The following section gives more details on the mapping of BITS to a FHIR Observation resource. ### Mapping BITs Enumerations to FHIR -FHIR has no data type that corresponds to this kind of measurement. Consequently we developed a code system which maps the BITs measurement to a set of codes. The details of the mapping and how these codes are generated from data received from the PHD are given in [ASN1 To HL7 CodeSystem](CodeSystem-ASN1ToHL7.html). Basically each component has a code consisting of the MDC code followed by the bit number. There is one component per reported bit setting. And similar to the compound measurement, there is no Observation.value[x] element. Each component has a value of "Y" or "N", corresponding to the bit being set or cleared. +FHIR has no data type that corresponds to this kind of measurement. Consequently we developed a code system which maps the BITs measurement to a set of codes. The details of the mapping and how these codes are generated from data received from the PHD are given in [ASN1 To HL7 CodeSystem](CodeSystem-ASN1ToHL7.html). Basically each component has a code consisting of the MDC code followed by the bit number. There is one component per reported bit setting. And similar to the compound measurement, there is no Observation.value[x] element. Each component has a value of `true` or `false`, corresponding to the bit being set or cleared. There may be an Observation.dataAbsentReason element if a measurement status indicates a measurement failure in which case no component elements representing the BITs setting are reported. diff --git a/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md b/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md index f250616..f73b26c 100644 --- a/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md +++ b/input/intro-notes/StructureDefinition-PhdBaseObservation-notes.md @@ -4,6 +4,7 @@ The following sections give more details on the data elements in a PHDBaseObserv HL7 has defined an extension for the Observation resource to reference a gateway device. This extension is used to reference the Device resource representing the Personal Health Gateway (PHG) device. ### Conditional-create Identifier - prevention of data duplication +<a name="ccidentifier"></a> The *Conditional-create Identifier* is defined to prevent data duplication. It can be used as the selection criterion in the conditional create when uploading observations. Ideally the PHG will implement a duplication detection mechanism and filter out any observations that have already been uploaded. One possible mechanism is to record the latest timestamp of any observation received during a connection. Then for a given device and patient and upload destination, on a subsequent connection the PHG can filter out any observations with a timestamp earlier than the recorded latest timestamp of the previous connection. The latest timestamp is then updated given the information received during the current connection. This filter not only saves the server from handling the conditional update transaction but saves bandwidth and upload costs. @@ -12,7 +13,7 @@ Additionally a globally unique identifier can be used in combination with a cond |Entry|value|Additional information| |---|---|---| -|device|`PHD Device.identifier.value`|This value is a hexadecimal representation of the PHD system identifier (16 hexadecimal characters for the IEEE EUI-64 identifier, 12 for the EUI-48 transport address identifier)| +|device|`PHD Device.identifier.value`|This value is a hexadecimal representation of the PHD system identifier (16 hexadecimal characters for the IEEE EUI-64 identifier, 12 for the EUI-48 transport address identifier) all capitals and without dashes| |patient|`Patient.identifier.value`-`Patient.identifier.system` or<br/>provided logical id|The dashes are part of the identifier. <br/>When the service provider gives the PHG a pre-determined patient logical id the PHG creates no Patient resource and has no patient information. In that situation the provided logical id is used| |type|`Observation.code.coding.code`|See [MDC Nomenclature codes](NomenclatureCodes.html) (decimal number)| |timestamp|`Observation.effectiveDateTime` or `Observation.effectivePeriod.start`|The reported PHD timestamp. See [Generating the PHD Reported Timestamp](GeneratingtheTimeStampPartIdentifier.html)| @@ -28,7 +29,7 @@ An example of the this identifier from [this example](Observation-numeric-spotnu {% fragment Observation/numeric-spotnumeric JSON EXCEPT:identifier %} ### Obtaining the Type of observation -One obtains the IEEE 11073-10101 observation type for the code element in the same manner for all metric observations. See the section [MDC Nomenclature codes](NomenclatureCodes.html) for the details of this mapping. +One obtains the IEEE 11073-10101 observation type for the code element in the same manner for all metric observations. See the section [MDC Nomenclature codes](NomenclatureCodes.html) for the details. ### Subject The subject element normally points to the PhdPatient resource using the logical id of the Patient resource, for example 'Patient/123546'. For device settings known to the PHG it should point to the PHD. @@ -44,36 +45,36 @@ border: 1px solid black; border-collapse:collapse; padding: 6px;}</style> -IEEE 11073-10206 timestamps represent a UTC time or a local time, that is synchronised with an external time source or not and can come with or without a TZ/DST offset or the timestamp represents a Tick Counter value. These timestamps can come from the current timeline of the PHD or not. In order to map a timestamp for the PHD's current timeline, the PHG needs the PHD's current time. +IEEE 11073-10206 timestamps represent a UTC time or a local time, that is synchronized with an external time source or not and can come with or without a TZ/DST offset or the timestamp represents a Tick Counter value. These timestamps can come from the current timeline of the PHD or not. In order to map a timestamp for the PHD's current timeline, the PHG needs the PHD's current time. A timestamp comes from the current timeline of the PHD if the PHD's clock progressed naturally without discontinuities since the time reported in the timestamp. This information is included in the timestamp reported by an IEEE 11073-10206 compliant PHD, such as Bluetooth devices following the GHS specification. More information can be found in the IEEE 11073-10206 ACOM and Bluetooth GHS specifications. -Observations with a timestamp that is not from the current timeline of the PHD and that are not from a timeline synchronised with an external time source should be thrown away since there is no way to give them a correct timestamp. +Observations with a timestamp that is not from the current timeline of the PHD and that are not from a timeline synchronized with an external time source should be thrown away since there is no way to give them a correct timestamp. The PHG can work with the assumption that the PHD and the PHG are always in the same time zone. This allows the PHG to set the offset of the timestamp to its offset. For IEEE 11073-10206 timestamps the following table can be used: -| Time type | Current | Synced | Offset | Recommended Mapping | Coincident Timestamp Observation | +| Time type | Current | Synced | Offset | Recommended Mapping | Coincident Timestamp Observation required | | ------------ | ------- | ------ | ------ | ----------------------------------------------------------------------- | --------------------------------- | -| UTC | Yes | Yes | Yes | Keep as is with optional correction to PHG timeline, keep offset as is | Yes | -| UTC | Yes | Yes | No | Keep as is, with optional correction and include PHG offset | Yes | +| UTC | Yes | Yes | Yes | Keep as is | No | +| UTC | Yes | Yes | No | Keep as is, but include PHG offset | No | | UTC | Yes | No | Yes | Map to PHG timeline, including PHG offset | Yes | | UTC | Yes | No | No | Map to PHG UTC timeline, include PHG offset | Yes | -| UTC | No | Yes | Yes | Keep as is | -| UTC | No | Yes | No | Keep as is, include PHG offset | -| UTC | No | No | Yes | Throw away | -| UTC | No | No | No | Throw away | -| Local | Yes | Yes | Yes | Map to UTC+offset with optional correction | -| Local | Yes | Yes | No | Map to UTC+offset, including PHG offset | -| Local | Yes | No | Yes | Map to PHG timeline, including PHG offset | -| Local | Yes | No | No | Map to PHG timeline, including PHG offset | -| Local | No | Yes | Yes | Map to UTC+offset | -| Local | No | Yes | No | Map to UTC, include PHG offset | -| Local | No | No | Yes | Throw away | -| Local | No | No | No | Throw away | -| Tick counter | Yes | n.a. | n.a. | Map to PHG timeline, including PHG offset | -| Tick counter | No | n.a. | n.a. | Throw away | +| UTC | No | Yes | Yes | Keep as is | No | +| UTC | No | Yes | No | Keep as is, include PHG offset | No | +| UTC | No | No | Yes | Throw away | n.a. | +| UTC | No | No | No | Throw away | n.a. | +| Local | Yes | Yes | Yes | Map to UTC+offset | Yes | +| Local | Yes | Yes | No | Map to UTC+offset, including PHG offset | Yes | +| Local | Yes | No | Yes | Map to PHG timeline, including PHG offset | Yes | +| Local | Yes | No | No | Map to PHG timeline, including PHG offset | Yes | +| Local | No | Yes | Yes | Map to UTC+offset | No | +| Local | No | Yes | No | Map to UTC+offset, include PHG offset | No | +| Local | No | No | Yes | Throw away | n.a. | +| Local | No | No | No | Throw away | n.a. | +| Tick counter | Yes | n.a. | n.a. | Map to PHG timeline, including PHG offset | Yes | +| Tick counter | No | n.a. | n.a. | Throw away | n.a. | The PHG maps the 'converted' timestamp to either an `Observation.effectiveDateTime` element or an `Observation.effectivePeriod` element. The second situation occurs when the metric observation includes a Measurement-Duration (duration) attribute. Then the timestamp attribute gives the start of the period and the end of the period is obtained by adding the Measurement-Duration value to it. If no timestamp is provided, the PHG, using the time of reception of the observation as its timestamp must then do the reverse; the time of reception is the end time and the start time is given by subtracting the Measurement-Duration value from it. When the PHG modifies an Observation's timestamp as received from the PHD it shall also generate a Coincident Timestamp observation that records how the Observation.effective[x] element is generated. @@ -89,7 +90,7 @@ The derivedFrom element references Observation resources that are in some manner The hasMember element is used when the PHD Observation reports a group of related observations. In GHS an Observation can have an Is Member Of attribute that references a group observation. When uploading to a FHIR server the gateway should report the group observation with a hasMember reference to all member Observations. -In GHS the sensor device related Observations are identified using a 32-bit Observation Id that is unique in the set of observations transferred during a connection. +In GHS the sensor related Observations are identified using a 32-bit Observation Id that is unique in the set of observations transferred during a connection. Related observations are best uploaded in a single FHIR Bundle with logical ids assigned. #### Source-Handle-Reference case (concept from IEEE 11073-20601 - deprecated) diff --git a/input/intro-notes/StructureDefinition-PhdDevice-intro.md b/input/intro-notes/StructureDefinition-PhdDevice-intro.md index 23d6e89..2255b3a 100644 --- a/input/intro-notes/StructureDefinition-PhdDevice-intro.md +++ b/input/intro-notes/StructureDefinition-PhdDevice-intro.md @@ -9,15 +9,15 @@ padding: 6px;}</style> |ACOM PHD attribute|FHIR Device element| |---|---| -|SystemInfo.System-identifier and/or *transport address* |identifier| -|*Friendly name*|deviceName| -|System-Type-Spec-List|specializations| -|SystemInfo.serial-number|serialNumber| -|SystemInfo.firmware-revision| version.value, version.type = MDC_ID_PROD_SPEC_FW| -|SystemInfo.hardware-revision| version.value, version.type = MDC_ID_PROD_SPEC_HW| -|SystemInfo.software-revision| version.value, version.type = MDC_ID_PROD_SPEC_SW| -|Clock attributes|properties| -|Power source attributes|properties| +|SystemInfo.System-identifier and/or *transport address* |`identifier`| +|*Friendly name*|`deviceName`| +|System-Type-Spec-List|`specializations`| +|SystemInfo.serial-number|`serialNumber`| +|SystemInfo.firmware-revision|`version.value`, `version.type` = MDC_ID_PROD_SPEC_FW| +|SystemInfo.hardware-revision|`version.value`, `version.type` = MDC_ID_PROD_SPEC_HW| +|SystemInfo.software-revision|`version.value`, `version.type` = MDC_ID_PROD_SPEC_SW| +|Clock attributes|`property` elements| +|Power source attributes|`property` elements| -The transport address and friendly name are not provided by the SystemInfo but come from the transport protocols. They may not be available and are therefore optional. However, if the PHD does not report a System-identifier, which may happen if one needs to map non-certified and/or proprietary devices, a transport address should be reported. It is still strongly recommended that the transport address is reported as it is often beneficial to the data consumers. Transport addresses of wireless devices are often printed on the device or the device packaging whereas the System-identifier is not. Most PHD transports provide a means of obtaining a transport address or an equivalent identifier such as a Bluetooth device address. +The transport address and friendly name are not provided by the SystemInfo but come from the transport protocols. They may not be available and are therefore optional. However, if the PHD does not report a System-identifier, which may happen if one needs to map non-certified and/or proprietary devices, a transport address should be reported. It is anyway recommended that the transport address is reported as it is often beneficial to the data consumers. Transport addresses of wireless devices are often printed on the device or the device packaging whereas the System-identifier is not. Most PHD transports provide a means of obtaining a transport address or an equivalent identifier such as a Bluetooth device address. diff --git a/input/intro-notes/StructureDefinition-PhdDevice-notes.md b/input/intro-notes/StructureDefinition-PhdDevice-notes.md index 72937c3..0375857 100644 --- a/input/intro-notes/StructureDefinition-PhdDevice-notes.md +++ b/input/intro-notes/StructureDefinition-PhdDevice-notes.md @@ -1,12 +1,14 @@ The section below describe the profiled elements in more detail. ### System Identifier → `Device.identifier` - All IEEE 11073-10206 PHDs are required to have a system identifier. This usually is an EUI-64 consisting of 8 bytes. The EUI-64 is mapped to the FHIR `Device.identifier.value` element as a sequence of 8 2-digit bytes as HEX separated by dashes without the '0x' prefix commonly used in programming languages. An example of such a string is FE-ED-AB-EE-DE-AD-77-C3. Though required by IEEE 11073-10206, it is not required in the Bluetooth Low Energy health device specifications. When a PHG encounters such a device it shall provide a transport address as a means of uniquely identifying the PHD. Supported transport addresses are Bluetooth and ZigBee. The Bluetooth address is an EUI-48, and the ZigBee address is an EUI-64. These will be encoded as strings just as the EUI-64. Note that USB.vid (vendor id) and USB.pid (product id) are not unique and cannot be used as system identifiers. + All IEEE 11073-10206 PHDs are required to have a system identifier. This usually is an EUI-64 consisting of 8 bytes. The EUI-64 is mapped to the FHIR `Device.identifier.value` element as a sequence of 8 2-digit capitalized HEX characters separated by dashes without the '0x' prefix commonly used in programming languages. An example of such a string is FE-ED-AB-EE-DE-AD-77-C3. Though required by IEEE 11073-10206, it is not required in the Bluetooth Low Energy health device specifications. When a PHG encounters such a device it shall provide a transport address as a means of uniquely identifying the PHD. Supported transport addresses are Bluetooth and ZigBee. The Bluetooth address is an EUI-48, and the ZigBee address is an EUI-64. These will be encoded as strings just as the EUI-64. In order to discriminate between an identifier that is a system id and that which is a transport address the `identifier.type` element is used. A dedicated CodeSystem [Device Identifier Codes](CodeSystem-ContinuaDeviceIdentifiers.html) has the codes one can use to populate the `identifier.type.coding.code` element. When in the future other system identifiers such as ETSI-ICCID (International Circuit Card Identifier) are used, this coding scheme will need to be extended. +Note that USB.vid (vendor id) and USB.pid (product id) pair identifies a product type from a vendor and cannot be used as system identifier. This information can be represented in a property element of the Device resource. + The transport addresses are as follows: <style>table, th, td { @@ -73,15 +75,19 @@ A fragment: ### Clock information The ACOM clock information is encoded in a set of `Device.property` elements. -#### Clock resolution → `Device.property` - The ACOM clock type and resolution is encoded as a `Device.property` element with the type code indicating the type of the clock. This is a code from [MDCClockResolutionTypes](ValueSet-MDCClockResolutionTypes.html). The value is scaled to a valueQuantity with microseconds `us` as unit. The system is `http://unitsofmeasure.org` (UCUM). +#### Clock type and resolution → `Device.property` + The ACOM clock type and resolution are encoded as a `Device.property` element with the type code indicating the type of the clock. + + The clock type is encoded in a property with an ASN1toHL7 code from [value set MDCClockResolutionTypes](ValueSet-MDCClockResolutionTypes.html) and a value "Y". + + The clock resolution is encoded as a property with a code from [MDCClockResolutionTypes](ValueSet-MDCClockResolutionTypes.html). The property value is scaled to a valueQuantity with microseconds `us` as unit. The system is `http://unitsofmeasure.org` (UCUM). The table below shows the types of clocks that ACOM supports and the codes used to indicate them. -|Clock Type|MDC Code| -|---|---| -|Wall Clock with DST and Time Zone offset (Base Offset Time)|68226| -|Wall Clock without DST and Time Zone offset (Absolute Time)|68222| -|Time Counter (Relative Time)|68223| +|Clock Type|MDC Code|ASN1toHL7 code (for resolution)| +|---|---|---| +|Wall Clock with offset (Base Offset Time)|68226|68219.7| +|Wall Clock without offset (Absolute Time)|68222|68219.0| +|Time Counter (Relative Time)|68223|68219.2 or 68219.3| In devices implementing the Bluetooth GHS profile specification the clock information is provided in the Elapsed Time characteristic. In other Bluetooth Low Energy devices the clock information may be inferred from the Current Time Service. @@ -91,7 +97,6 @@ In devices implementing the Bluetooth GHS profile specification the clock inform |ACOM time capability|`Device.property.type.coding.code`| |---|---| |Set Clock is supported|68219.1| -|Base Offset Time is supported|68219.7| |DST Rules are supported|68219.15| Other codes from the valueSet are not used in ACOM, but are present to support the older IEEE 1103-20601 model. The value of the property is a Boolean value indicating whether the capability is supported or not. diff --git a/input/intro-notes/StructureDefinition-PhdNumericObservation-notes.md b/input/intro-notes/StructureDefinition-PhdNumericObservation-notes.md index 3b2ed57..dabcf08 100644 --- a/input/intro-notes/StructureDefinition-PhdNumericObservation-notes.md +++ b/input/intro-notes/StructureDefinition-PhdNumericObservation-notes.md @@ -19,7 +19,7 @@ The accuracy is reported in the same unit as the measurement itself. An example {% fragment Observation/temperature-observation JSON EXCEPT:extension[3] %} ##### Simple Alerting -The simple alerting extension supports monitoring a numerical value (quantities in FHIR) and provisioning of an alarm if the value is outside a defined threshold or limiting range. The extension includes the range, the operational state of the monitoring and text strings desribing these. See [Simple Alerting](StructureDefinition-SimpleAlerting.html). The PHD pulse oximeter and the continuous glucose monitor specialization support this. +The simple alerting extension supports monitoring a numerical value (quantities in FHIR) and provisioning of an alarm if the value is outside a defined threshold or limiting range. The extension includes the range, the operational state of the monitoring and text strings describing these. See [Simple Alerting](StructureDefinition-SimpleAlerting.html). The PHD pulse oximeter and the continuous glucose monitor specialization support this. The extension defines a current limits range for the quantity, an operational state and optional strings for the operational state and the semantics of the quantity being outside the range. This mechanism is used in combination with the `Observation.interpretation` value being set to "in-alarm" when the quantity is outside the limits. @@ -43,7 +43,7 @@ A basic simple numeric observation with a timestamp and a supplemental types att An example of a NaN (not a number) measurement is shown in [NaN Example](Observation-numeric-observation-not-a-number.html). Note that the value element is absent and replaced by a dataAbsentReason element. ### Consumer of the PHD Numeric Observation Profile -The consumer of this profile does not need to concern itself with the mapping complexities or the PHD-related entry for the `Observation.identifier` which is used by the uploader to prevent data duplication. There are some extensions introduced by this profile but the resource is consumable by any reader that understands the Observation resource. The following table summarizes the elements used describing the measurement: +The consumer of this profile does not need to concern itself with the complexities or the PHD-related entry for the `Observation.identifier` which is used by the uploader to prevent data duplication. There are some extensions introduced by this profile but the resource is consumable by any reader that understands the Observation resource. The following table summarizes the elements used describing the measurement: | **Measurement Item** | **Element** | **Additional Information** | |-------------------------------|------------------------------------------|-----------------------------------------------------------------------------------------------------------------| diff --git a/input/intro-notes/StructureDefinition-PhdPatient-intro.md b/input/intro-notes/StructureDefinition-PhdPatient-intro.md index 453157b..0cd702a 100644 --- a/input/intro-notes/StructureDefinition-PhdPatient-intro.md +++ b/input/intro-notes/StructureDefinition-PhdPatient-intro.md @@ -1,6 +1,6 @@ -A Patient resource adhering to the PHD Patient Profile is used as a reference for most Observations. Dependent on the use case, the Patient resource may contain only minimal information sufficient to identify the patient resource on the server. It is also possible that the Patient resource is never uploaded by the PHG. In that case, the logical id to a Patient resource on the FHIR server must be provided to the PHG by out-of-band means. +A Patient resource adhering to the PHD Patient Profile is used as a reference for most Observations. Dependent on the use case, the Patient resource may contain only minimal information sufficient to identify the patient resource on the server. It is also possible that the Patient resource is never uploaded by the PHG. In that case, the logical id to a Patient resource on the FHIR server must be provided to the PHG by some other means. The PHD Patient Profile may or may not include patient-identifiable information, depending on the use case. For example, in Remote Patient Monitoring, PII/PHI protection may be critical, while in other cases, such as fitness tracking by a coach monitoring team performance. In such cases, protecting fitness data may not justify the associated effort and inconvenience. This profile supports both scenarios. -If a Patient resource is created, only `Patient.identifier.system`, `Patient.identifier.value`, `Patient.identifier.type.coding.code`, and `Patient.identifier.type.coding.system` are required. The `Patient.name` element is optional, helping in PII/PHI protection since required fields cannot be linked to a person without a dictionary that should only be available to the healthcare provider. +If a Patient resource is created by the PHG, only `Patient.identifier.system`, `Patient.identifier.value`, `Patient.identifier.type.coding.code`, and `Patient.identifier.type.coding.system` are required. The `Patient.name` element is optional, helping in PII/PHI protection since the required fields cannot be linked to a person without a dictionary that should only be available to the healthcare provider. diff --git a/input/intro-notes/StructureDefinition-PhdPatient-notes.md b/input/intro-notes/StructureDefinition-PhdPatient-notes.md index ce8b617..6c8821a 100644 --- a/input/intro-notes/StructureDefinition-PhdPatient-notes.md +++ b/input/intro-notes/StructureDefinition-PhdPatient-notes.md @@ -3,18 +3,15 @@ border: 1px solid black; border-collapse:collapse; padding: 6px;}</style> -### Mapping -A Patient resource for a known or an unknown patient shall be created by the PHG according to the following mapping: - -|patient information|FHIR mapping|Value for a known patient|Value for an unknown patient| -|- -|patient identifier|Patient.identifier.value|Generally a code from the health care provider identifying the patient|'U'| -|health care provider identifier|Patient.identifier.system|Generally a code identifying the health care provider|[http://terminology.hl7.org/CodeSystem/v2-0004](http://terminology.hl7.org/CodeSystem/v2-0004)| -|fixed coding system|Patient.identifier.type.coding.system|[http://terminology.hl7.org/CodeSystem/v2-0203](http://terminology.hl7.org/CodeSystem/v2-0203)|[http://terminology.hl7.org/CodeSystem/v2-0203](http://terminology.hl7.org/CodeSystem/v2-0203)| -|code |Patient.identifier.type.coding.code|A code such as 'MR' (medical record) or 'LR' (local registry) from the above coding system|'U'| +### PHG created Patient Resource +A Patient resource for a known or an unknown patient shall be created by the PHG according to this profile. This implies: +- The Patient resource shall have a `Patient.identifier` element from a known [HL7 v2-0203](http://terminology.hl7.org/CodeSystem/v2-0203) coding system. +- As an example the `MR` (Medical Record) code from this coding system may be used. +- The `Patient.identifier.value` element shall contain a value that is unique for the patient in the context of the health care provider. ### Examples: -An example of a PHD patient mapping for a known patient is given [here](Patient-patientExample-1.html). The example contains an optional name element.<br> -An example of a PHD patient mapping for an unknown patient is given [here](Patient-patientExample-2.html). The example contains an optional name element. +An example of a PHD generated patient for a known patient is given [here](Patient-patientExample-1.html). +An example of a PHD generated patient for an unknown patient is given [here](Patient-patientExample-2.html). +These examples contain an optional name element. diff --git a/input/intro-notes/StructureDefinition-PhgDevice-intro.md b/input/intro-notes/StructureDefinition-PhgDevice-intro.md index e738e4b..115f33d 100644 --- a/input/intro-notes/StructureDefinition-PhgDevice-intro.md +++ b/input/intro-notes/StructureDefinition-PhgDevice-intro.md @@ -4,7 +4,7 @@ PHGs may be implemented on a mobile phone, a personal computer, or in a dedicate A PHG does not have an System-Information and Clock object, but for the purposes of reporting the PHG information, like its system identifier, time synchronization, and serial number, these values are treated *as if* they came from these objects. -Unlike the PHD where one reports the information if delivered, in the PHG case far fewer fields are required to be reported. The following table summarizes the required fields and their mappings: +Unlike the PHD where one reports the information if delivered, in the PHG case far fewer fields are required to be reported. The following table summarizes the required fields and their FHIR representation: <style>table, th, td { border: 1px solid black; diff --git a/input/intro-notes/StructureDefinition-SimpleAlerting-notes.md b/input/intro-notes/StructureDefinition-SimpleAlerting-notes.md index 663ea3c..e07e774 100644 --- a/input/intro-notes/StructureDefinition-SimpleAlerting-notes.md +++ b/input/intro-notes/StructureDefinition-SimpleAlerting-notes.md @@ -16,7 +16,7 @@ The `currentLimits` element specifies the acceptable range for the monitored par - **Units**: The limits are expressed in a specific unit (e.g., `%` for percentages) using the Unified Code for Units of Measure (UCUM) and should match the unit of the monitored parameter. ## Alert Operational State -The IEEE 11073-10206 Alert Operational State attribute uses an ASN1-BITs field to indicate whether the alerts on a given limit (upper or lower) are on or off. When `SET`, the alerts are off. This is a state-type measurement, and when this attribute is present, both the set and cleared states are reported. The MDC code of the attribute is `MDC_ATTR_AL_OP_STAT`. +The IEEE 11073-10206 Alert Operational State attribute uses an ASN1-BITs field to indicate whether the alerts on a given limit (upper or lower) are on or off. When `SET`, the alerts are off. This is a state-type measurement, and when this attribute is present, both the set and cleared states are reported. The MDC reference Identifier of the attribute is `MDC_ATTR_AL_OP_STAT`. The `alertOperationalState` element indicates the current operational state of the alerting system. It is represented as a `valueCodeableConcept` with codes from the `SimpleAlertOperationalStates` ValueSet. Examples of operational states include: - **`On`**: The alerting system is active and monitoring the parameter. @@ -25,7 +25,7 @@ The `alertOperationalState` element indicates the current operational state of t - **`LimitsOff`**: Both upper and lower limit monitoring are disabled. ## Alert Operational Text -The IEEE 11073-10206 Alert Operational Text attribute consists of a pair of strings that describe the operational state of the lower and upper threshold monitoring. +The IEEE 11073-10206 Alert Operational Text attribute consists of a pair of strings that describe the operational state of the lower and upper threshold monitoring. The MDC reference Identifier is `MDC_ATTR_AL_OP_TEXT_STRING`. The `alertOperationalText` element provides a single human-readable string describing the operational state of the lower and upper threshold monitoring. diff --git a/input/pagecontent/CoincidentTimeStamp.md b/input/pagecontent/CoincidentTimeStamp.md index b1d7b6d..7c67d3f 100644 --- a/input/pagecontent/CoincidentTimeStamp.md +++ b/input/pagecontent/CoincidentTimeStamp.md @@ -44,5 +44,5 @@ As an example, say the PHG reads the current time of the PHD and sees that it is ### Mapping Tick Counters PHDs may also use tick counters of a specified resolution that report a tick count or relative time. GHS supports resolutions of 1 second to 100 microseconds. With relative times there is no check for which device is better synchronized. The PHG must always map the value to UTC plus offset. The PHD's current time is reported in the `Observation.valueQuantity` element scaled to the tick counter's resolution. This time provides the anchor time allowing the PHG to map the relative times reported in measurements to its own timeline in UTC plus offset format. -A relative timestamp value in a measurement is mapped to UTC plus offset by taking the difference between the measurement timestamp and the synchronisation point's relative time. That difference is added to the synchronisation point's UTC time plus offset. For example, if the PHD is using the 1 millisecond relative time and the PHG obtains the current relative time 'anchor' value of 100000 at the PHG's current time 'anchor' value of 2017/11/27 05:31:44.555 -0500 then the PHG can map a measurement timestamp of 108000 to an actual time of 2017/11/27 05:31:52.555 -0500 since 108000 - 100000 = 8000 milliseconds. +A relative timestamp value in a measurement is mapped to UTC plus offset by taking the difference between the measurement timestamp and the synchronization point's relative time. That difference is added to the synchronization point's UTC time plus offset. For example, if the PHD is using the 1 millisecond relative time and the PHG obtains the current relative time 'anchor' value of 100000 at the PHG's current time 'anchor' value of 2017/11/27 05:31:44.555 -0500 then the PHG can map a measurement timestamp of 108000 to an actual time of 2017/11/27 05:31:52.555 -0500 since 108000 - 100000 = 8000 milliseconds. diff --git a/input/pagecontent/DIMtoFHIRMapping.md b/input/pagecontent/DIMtoFHIRMapping.md index 053ad16..69b509f 100644 --- a/input/pagecontent/DIMtoFHIRMapping.md +++ b/input/pagecontent/DIMtoFHIRMapping.md @@ -69,7 +69,7 @@ The table below illustrates the mapping of a Compound Observation with *N* numer |components[N].value|Gives value of the *N*th component of the measurement|`component[N].valueQuantity.value`| |components[N].unit|Gives the units of the *N*th component of the measurement as an IEEE 11073-10101 code. Shall be translated to the equivalent UCUM code and system when available.|`component[N].valueQuantity.code`| -This mapping applies to simple types of PHD measurements that are represented by vectors, for example, the blood pressure and the user feedback. The Type attribute indicates what the overall measurement is, and the components[].component-type indicates what each component of the overall measurement is. In the blood pressure case, the Type states that this is a non-invasive blood pressure and the component-type attribute identifies the systolic, diastolic, and MAP components. This implementation guide specifies a structure definition profile that applies to all Compound Observations. A dedicated profile for Compound Numeric Observations is present for backwards compatibility. +This mapping applies to simple types of PHD measurements that are represented by vectors, for example, the blood pressure and the user feedback. The Type attribute indicates what the overall measurement is, and the component-type indicates what each the type of each component is. In the blood pressure case, the Type states that this is a non-invasive blood pressure and the component-type attribute identifies the systolic, diastolic, and MAP components. This implementation guide specifies a structure definition profile that applies to all Compound Observations. A dedicated profile for Compound Numeric Observations is present for backwards compatibility. ### Discrete Observation Mapping Example The simplest example of a mapping of a discrete observation, where the measurement is a code, to a FHIR Observation resource is as follows: diff --git a/input/pagecontent/ProfileConsumers.md b/input/pagecontent/ProfileConsumers.md index e136732..ecb3539 100644 --- a/input/pagecontent/ProfileConsumers.md +++ b/input/pagecontent/ProfileConsumers.md @@ -82,7 +82,7 @@ In addition to the elements that are always present, the following set of elemen |clock.current-time |`Observation.extension.valueReference`|Points to Observation following the Coincident Timestamp Observation profile that records the PHD's current time. This is used for time quality auditing purposes. May be present only when the PHD provides a timestamp. | |related observations|`Observation.derivedFrom` `Observation.hasMember`|Points to a PHD Observation that is related to this Observation. An example would be an activity session that has a miles run measurement member. Only present if the observation references another observation.| |additional descriptions|`Observation.component` or `Observation.extension`|Sometimes a measurement is sent containing additional information such as the technique used to obtain the measurement. These elements are placed in a component or an extension.| -||`Observation.identifier`|This element is used to prevent data duplication during uploads.| +||`Observation.identifier`|A unique identifier can be generated and used by a PHG and to prevent data duplication during uploads.| ##### The Profile: `Observation.meta.profile` An Observation may contain a `meta.profile` element that can help to identify the type of the Observation. For example, if `Observation.profile` entry contains ["http://hl7.org/fhir/uv/phd/StructureDefinition/PhdNumericObservation"](StructureDefinition-PhdNumericObservation.html) the measurement is a scalar. @@ -149,7 +149,7 @@ The exact mapping of IEEE 11073-10206 Observation status conditions to FHIR is c In addition to the conditions listed above, when the measurement value is a quantity, PHDs may also report one of a set of special values, "Not a Number", "Not at this resolution", "Positive infinity", or "Negative infinity". These errors can results from a failure of the floating point software or hardware, or the inability of the sensor to completely acquire a value. These errors are reported in the dataAbsentReason element and will be discussed in the sections discussing the measurement values. "Not a Number" is the most common special condition reported by PHDs currently on the market. Reporting of the other special situations listed above are, in practice, rare. #### Identifier -To prevent data duplication during uploads, and enable use of conditional create transactions, identifiers are provided for the Observations described in this IG. No additional meaning is associated with those identifiers. Other systems may add further identifiers. +To prevent data duplication during uploads, and enable use of conditional create transactions, identifiers are provided for the Observations described in this IG. No additional meaning is associated with those identifiers. Details can be found in the [Identifier section](StructureDefinition-PhdBaseObservation.html#ccidentifier). Other systems may add further identifiers. <a id="numerics"></a> ### Measurement Values that are numeric or scalar @@ -361,7 +361,7 @@ The **bold** items are required to be reported by all PHDs and the italicized it The UDI (Unique Device Identifier) is supported by the PHD Device profile as an optional element. It is supported by the IEEE 11073-10206 standard and the Bluetooth GHS specifications. When provided by the PHD the actual UDI string will be in human readable form and comes with metadata identifying the issuer and the regulatory authority #### Device identifier -The identifier contains elements that (are intended to) uniquely identify the PHD. To distinguish one identifier type from another a code from the [ContinuaDeviceIdentifiers](CodeSystem-ContinuaDeviceIdentifiers.html) code system is used in the Device.identifier.type. Supported codes include the IEEE EUI-64 System Identifier and transport-based identifiers. See the [CodeSystem-ContinuaDeviceIdentifiers](CodeSystem-ContinuaDeviceIdentifiers.html) for the complete list of codes. +The identifier contains elements that (are intended to) uniquely identify the PHD. To distinguish one identifier type from another a code from the [ContinuaDeviceIdentifiers](CodeSystem-ContinuaDeviceIdentifiers.html) code system is used in the Device.identifier.type. Supported codes include the IEEE EUI-64 System Identifier and transport-based identifiers. See the [CodeSystem-ContinuaDeviceIdentifiers](CodeSystem-ContinuaDeviceIdentifiers.html) for the complete list of codes. These identifiers are formatted as hexadecimal strings with each pair of characters separated by dashes and using capitals. An example is shown below: