From 5cfede62a7db0a2b2a0b1af78aa8b57fe01d967b Mon Sep 17 00:00:00 2001 From: Erik Moll Date: Thu, 31 Jul 2025 16:47:03 +0200 Subject: [PATCH 1/2] Update ProfileConsumers.md --- input/pagecontent/ProfileConsumers.md | 39 +++++++++++++-------------- 1 file changed, 19 insertions(+), 20 deletions(-) diff --git a/input/pagecontent/ProfileConsumers.md b/input/pagecontent/ProfileConsumers.md index de0cb74..597d155 100644 --- a/input/pagecontent/ProfileConsumers.md +++ b/input/pagecontent/ProfileConsumers.md @@ -50,7 +50,18 @@ FHIR requires that a LOINC code is present if the measurement is one of the vita In addition to the LOINC code, FHIR requires an `Observation.category` element with value "vital-signs" when the measurement is a vital sign. -#### The Timestamp: `Observation.effective[x]` +##### 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. + +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. + +The exact mapping of IEEE 11073-10206 Observation status conditions to FHIR is covered in the [PhdBaseObservation profile](StructureDefinition-PhdBaseObservation.html). + +In addition to the conditions listed above, when the measurement value is a quantity, PHDs may also report one of a set of special FLOAT 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. + +##### The Timestamp: `Observation.effective[x]` 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. @@ -59,17 +70,17 @@ Below is an example of the `effective[x]` when the timestamp is an instant in ti {% fragment Observation/temperature-observation JSON EXCEPT:effectiveDateTime %} -#### The PHG reference extension +##### The PHG reference extension The reference to the Device resource containing the PHG properties is encoded in an extension element. An example of the PHG extension is shown below: {% fragment Observation/temperature-observation JSON EXCEPT:extension[0] %} -#### The Patient reference: `Observation.subject`: +##### 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 PHD reference 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. @@ -96,14 +107,14 @@ An example of the Coincident Timestamp extension is shown below: {% fragment Observation/temperature-observation JSON EXCEPT:extension[1] %} -#### References to Other Observations +##### Related Observations There are situations where a given Observation is derived from or part of another Observation such as a BMI observation being derived from a height and weight measurement. In that case the Observation will have `Observation.derivedFrom` elements that point to the Observation resources containing the height and weight 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 is referenced from the master session Observation in an `Observation.hasMember` element. An example of a reference to another Observation is shown below: {% fragment Observation/bpm-status JSON EXCEPT:derivedFrom %} -#### Additional Descriptive Data +##### 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` or an `Observation.extension` element. The type of additional information is given by the `Observation.component.code` or `Observation.extension.url` element. The value of such additional information is given by an `Observation.component.value[x]` or an `Observation.extension.value[x]` element. PHDs support the following types of additional information: @@ -117,7 +128,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 Types Supplemental type information is indicated by the `Observation.component.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] %} @@ -134,21 +145,9 @@ In the PHD IG v1.0 an attempt was made to avoid extensions as much as possible. Input is welcome! -#### Identifier +##### 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. Details can be found in the [Identifier section](StructureDefinition-PhdBaseObservation.html#ccidentifier). Other systems may add further identifiers. -### 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. - -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. - -The exact mapping of IEEE 11073-10206 Observation status conditions to FHIR is covered in the [PhdBaseObservation profile](StructureDefinition-PhdBaseObservation.html). - -In addition to the conditions listed above, when the measurement value is a quantity, PHDs may also report one of a set of special FLOAT 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. - - ### 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. From e1c46c20b3fdc6e7f3d7878e5c96ae879ce1f7d2 Mon Sep 17 00:00:00 2001 From: Erik Moll Date: Wed, 6 Aug 2025 10:27:22 +0200 Subject: [PATCH 2/2] fixing publication issue around absence of logical ids in examples --- input-cache/jiraspec.xml | 4 ++-- input/examples/glucose-observation.json | 1 + input/examples/meal-context-observation.json | 1 + input/examples/rtsa-example-2.json | 1 + input/examples/rtsa-example.json | 1 + input/examples/string-observation-1.json | 1 + input/examples/temperature-observation.json | 1 + input/fsh/CodeSystem.ASN1ToHL7.fsh | 8 ++++---- .../StructureDefinition.CoincidentTimeStampReference.fsh | 4 ++-- input/ignoreWarnings.txt | 5 ++++- input/intro-notes/Observation-bits-observation-intro.md | 4 +++- .../Observation-numeric-observation-not-a-number-intro.md | 4 +++- .../intro-notes/Observation-numeric-spotnumeric-intro.md | 4 +++- .../intro-notes/Observation-string-observation-1-intro.md | 2 +- 14 files changed, 28 insertions(+), 13 deletions(-) diff --git a/input-cache/jiraspec.xml b/input-cache/jiraspec.xml index 012f8cb..d50e60e 100644 --- a/input-cache/jiraspec.xml +++ b/input-cache/jiraspec.xml @@ -1,9 +1,9 @@ - + - + diff --git a/input/examples/glucose-observation.json b/input/examples/glucose-observation.json index 01d6d7d..f1b391d 100644 --- a/input/examples/glucose-observation.json +++ b/input/examples/glucose-observation.json @@ -1,5 +1,6 @@ { "resourceType": "Observation", + "id": "glucose-observation", "meta": { "profile": [ "http://hl7.org/fhir/uv/phd/StructureDefinition/PhdNumericObservation" diff --git a/input/examples/meal-context-observation.json b/input/examples/meal-context-observation.json index 0fd473c..b165435 100644 --- a/input/examples/meal-context-observation.json +++ b/input/examples/meal-context-observation.json @@ -1,5 +1,6 @@ { "resourceType": "Observation", + "id": "meal-context-observation", "meta": { "profile": [ "http://hl7.org/fhir/uv/phd/StructureDefinition/PhdCodedEnumerationObservation" diff --git a/input/examples/rtsa-example-2.json b/input/examples/rtsa-example-2.json index 2d26a10..9332bad 100644 --- a/input/examples/rtsa-example-2.json +++ b/input/examples/rtsa-example-2.json @@ -1,5 +1,6 @@ { "resourceType": "Observation", + "id": "rtsa-example-2", "meta": { "profile": [ "http://hl7.org/fhir/uv/phd/StructureDefinition/PhdRtsaObservation" diff --git a/input/examples/rtsa-example.json b/input/examples/rtsa-example.json index 37610c7..5c92799 100644 --- a/input/examples/rtsa-example.json +++ b/input/examples/rtsa-example.json @@ -1,5 +1,6 @@ { "resourceType": "Observation", + "id": "rtsa-example", "meta": { "profile": [ "http://hl7.org/fhir/uv/phd/StructureDefinition/PhdRtsaObservation" diff --git a/input/examples/string-observation-1.json b/input/examples/string-observation-1.json index 54a5da1..40a519d 100644 --- a/input/examples/string-observation-1.json +++ b/input/examples/string-observation-1.json @@ -1,5 +1,6 @@ { "resourceType": "Observation", + "id":"string-observation-1", "meta": { "profile": [ "http://hl7.org/fhir/uv/phd/StructureDefinition/PhdStringObservation" diff --git a/input/examples/temperature-observation.json b/input/examples/temperature-observation.json index 9a5ea94..7d641ac 100644 --- a/input/examples/temperature-observation.json +++ b/input/examples/temperature-observation.json @@ -1,5 +1,6 @@ { "resourceType": "Observation", + "id": "temperature-observation", "meta": { "profile": [ "http://hl7.org/fhir/uv/phd/StructureDefinition/PhdNumericObservation" diff --git a/input/fsh/CodeSystem.ASN1ToHL7.fsh b/input/fsh/CodeSystem.ASN1ToHL7.fsh index 17530e0..05f4590 100644 --- a/input/fsh/CodeSystem.ASN1ToHL7.fsh +++ b/input/fsh/CodeSystem.ASN1ToHL7.fsh @@ -20,10 +20,10 @@ Description: "CodeSystem for mapping IEEE 11073-10206 bitstrings to FHIR Codeabl * ^publisher = "Health Level Seven International (Devices Work Group)" * ^caseSensitive = true * ^content = #complete -* ^extension[+].url = "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status" -* ^extension[=].valueCode = #trial-use -* ^extension[=].valueCode.extension.url = "http://hl7.org/fhir/StructureDefinition/structuredefinition-conformance-derivedFrom" -* ^extension[=].valueCode.extension.valueCanonical = "http://terminology.hl7.org/CodeSystem/ASN1ToHL7" +// * ^extension[+].url = "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status" +// * ^extension[=].valueCode = #trial-use +// * ^extension[=].valueCode.extension.url = "http://hl7.org/fhir/StructureDefinition/structuredefinition-conformance-derivedFrom" +// * ^extension[=].valueCode.extension.valueCanonical = "http://terminology.hl7.org/CodeSystem/ASN1ToHL7" * ^property[0].code = #eventOrState diff --git a/input/fsh/StructureDefinition.CoincidentTimeStampReference.fsh b/input/fsh/StructureDefinition.CoincidentTimeStampReference.fsh index 32faaf0..2f2e707 100644 --- a/input/fsh/StructureDefinition.CoincidentTimeStampReference.fsh +++ b/input/fsh/StructureDefinition.CoincidentTimeStampReference.fsh @@ -9,8 +9,8 @@ Context: Observation * ^extension[=].valueCode = #dev * ^extension[+].url = "http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm" * ^extension[=].valueInteger = 1 -* ^extension[+].url = "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status" -* ^extension[=].valueCode = #trial-use +// * ^extension[+].url = "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status" +// * ^extension[=].valueCode = #trial-use * ^extension[+].url = "http://hl7.org/fhir/StructureDefinition/structuredefinition-type-characteristics" * ^extension[=].valueCode = #can-bind * ^url = "http://hl7.org/fhir/uv/phd/StructureDefinition/CoincidentTimeStampReference" diff --git a/input/ignoreWarnings.txt b/input/ignoreWarnings.txt index 7beb52f..486d3db 100644 --- a/input/ignoreWarnings.txt +++ b/input/ignoreWarnings.txt @@ -31,7 +31,10 @@ The type of property 'code' is 'code', but no ValueSet information was found, so This element does not match any known slice defined in the profile http://hl7.org/fhir/uv/phd/StructureDefinition/PhdNumericObservation|2.0.0-ballot2 (this may not be a problem, but you should check that it's not intended to match a slice) # This informational message is due to inheriting this extension from the core specification. -The extension http://hl7.org/fhir/StructureDefinition/elementdefinition-maxValueSet|5.2.0 is deprecated +The extension http://hl7.org/fhir/StructureDefinition/elementdefinition-maxValueSet|5.3.0-ballot-tc1 is deprecated with the note Use additionalBinding extension or element instead + +# We will switch to the new Device Gateway extension in the next version of the PHD IG. +The extension http://hl7.org/fhir/StructureDefinition/observation-gatewayDevice|5.3.0-ballot-tc1 is deprecated with the note Use Device Gateway (device-gateway) extension which allows codeableReference (Device) in R6 and requires cross version extension for codeable reference. # This warning is generated on purpose in two examples that use a private code on purpose. This warning can hence safely be ignored. Constraint failed: mdc-1: 'A published MDC Code is preferred but private MDC codes are allowed as well.' (defined in http://hl7.org/fhir/uv/phd/StructureDefinition/PhdBaseObservation) diff --git a/input/intro-notes/Observation-bits-observation-intro.md b/input/intro-notes/Observation-bits-observation-intro.md index 73b8ed1..02b24fa 100644 --- a/input/intro-notes/Observation-bits-observation-intro.md +++ b/input/intro-notes/Observation-bits-observation-intro.md @@ -6,4 +6,6 @@ The source of the ASN1 names comes from the IEEE 11073-11404 (pulse Oximeter) sp The PHD does not send timestamps with its measurements therefore the timestamp is the time of reception by the PHG and there is no coincident timestamp Observation. -Note there is no logical id in this resource as this resource is being uploaded to the server in a create operation. The server will create the logical id and return it to the sender in the response. There is also no reference to the coincident timestamp since this observation is generated by a device that is streaming data and reporting no timestamp. The timestamp is taken to be the time of reception by the gateway. \ No newline at end of file +Note there is no need for a logical id in this resource when this resource is being uploaded to the server in a create operation. The server will create the logical id and return it to the sender in the response. There is also no reference to the coincident timestamp since this observation is generated by a device that is streaming data and reporting no timestamp. The timestamp is taken to be the time of reception by the gateway. + +The logical id in the example is present due to limitations of the publishing process. \ No newline at end of file diff --git a/input/intro-notes/Observation-numeric-observation-not-a-number-intro.md b/input/intro-notes/Observation-numeric-observation-not-a-number-intro.md index fd0ea23..c2e20b7 100644 --- a/input/intro-notes/Observation-numeric-observation-not-a-number-intro.md +++ b/input/intro-notes/Observation-numeric-observation-not-a-number-intro.md @@ -1,4 +1,6 @@ This is an example of a device reporting a NaN (not a number). The important aspect of this case is that the `value[x]` element is absent and replaced by a `dataAbsentReason` element. -There is no logical id in this resource as this resource is being uploaded to the server in a create operation. The server will create the logical id and return it to the sender in the response. There is also no reference to the coincident timestamp since this observation is generated by a device that is streaming data as it is generated and without a timestamp. The timestamp is taken to be the time of reception by the gateway. +Note there is no need for a logical id in this resource when this resource is being uploaded to the server in a create operation. The server will create the logical id and return it to the sender in the response. There is also no reference to the coincident timestamp since this observation is generated by a device that is streaming data as it is generated and without a timestamp. The timestamp is taken to be the time of reception by the gateway. + +The logical id in the example is present due to limitations of the publishing process. diff --git a/input/intro-notes/Observation-numeric-spotnumeric-intro.md b/input/intro-notes/Observation-numeric-spotnumeric-intro.md index 7a20ce0..6af2bbf 100644 --- a/input/intro-notes/Observation-numeric-spotnumeric-intro.md +++ b/input/intro-notes/Observation-numeric-spotnumeric-intro.md @@ -1,5 +1,7 @@ This example shows a basic numeric observation. It does have an additional component as the measurement also contained a Supplemental Information attribute indicating the measurement is a SPOT (stable average). -Note there is no logical id in this resource as this resource is being uploaded to the server in a conditional create operation. The server will use the conditional create identifier to check that no other Observation resource exists on the server with the same identifier. If there is not such resource present, the server will create the logical id and return it to the sender in the response. Pulse oximeters reporting a SPOT measurement have a timestamp thus there is a reference to the coincident timestamp. +Note there is no logical id needed in this resource when this resource is being uploaded to the server in a conditional create operation. The server will use the conditional create identifier to check that no other Observation resource exists on the server with the same identifier. If there is not such resource present, the server will create the logical id and return it to the sender in the response. Pulse oximeters reporting a SPOT measurement have a timestamp thus there is a reference to the coincident timestamp. + +The logical id in the example is present due to limitations of the publishing process. The referenced resources are assumed to have been uploaded to the server before - Patient, PHD, PHG and coincident timestamp. \ No newline at end of file diff --git a/input/intro-notes/Observation-string-observation-1-intro.md b/input/intro-notes/Observation-string-observation-1-intro.md index ec7436b..edead33 100644 --- a/input/intro-notes/Observation-string-observation-1-intro.md +++ b/input/intro-notes/Observation-string-observation-1-intro.md @@ -1,3 +1,3 @@ This example is an observation coming from a glucose meter and explains why a measurement failed. There is no such measurement type defined in the Glucose specialization so this manufacturer used a private attribute. -Note there is no logical id in this resource as this resource is being uploaded to the server in a create operation. The server will create the logical id and return it to the sender in the response. \ No newline at end of file +Note there is no logical id needed in this resource when this resource is being uploaded to the server in a create operation. The server will create the logical id and return it to the sender in the response. The logical id in the example is present due to limitations of the publishing process. \ No newline at end of file