Representing Patient Vital Signs

Printer Friendly, PDF & Email

Comment

Submitted by mkirwan@pchall… on 2017-11-20

Section I – V Transmitting a Unique Device Identifier

Please make the following changes:

1.Please add row for  “Implementation” and add “IEEE 11073 PHD Harmonization Pattern for Unique Device Identifiers”. The remaining fields are the same as for HL7 Harmonization…

Submitted by mkirwan@pchall… on 2017-11-20

Section I – V Representing Patient Vital Signs

Please make the following changes:

1.For 2nd row, ISO/IEEE 11073 Implementation Maturity should be noted as Production

2.The Adoption Level at least 3 dots.

3.The test tool availability should be noted as Yes.

4.Add the following note to the Dependencies section for Consideration: See Continua CODE for Healthcare in the Interoperability Proving Ground. Link: https://www.healthit.gov/techlab/ipg/node/4/submission/2046

Submitted by mkirwan@pchall… on 2017-11-20

Section I - V Representing Patient Vital Signs

For adoption one should mention that the MDC codes are being adopted into FHIR and has become the defacto representation for device data by the HL7 Devices on FHIR profiles for PHD and PoCD representations.

Background: 

Regarding 'Test tool availability':
I know there is room for improvement (in terms of quality and clinical value) but don't we have test tools for IHE profiles based on 11073 already nicely provided by the National Institute of Standards and Technology:
http://ihe-pcd-precon.nist.gov/PCD-HL7WebPreCon/
For 11073-10103 we work together with the heart rhythm society for years now and soon more representatives from Europe to improve the clinical value of the standard and tests of the nomenclature 11073-10103.

Regarding 'Federally required':
A number of 11073 nomenclatures may soon become required (!) by the Austrian Federal Ministry of Health for example. Italy already had national tenders requesting to be compliant to IHE IDCO based on 11073.
FDA already labels some of the 11073 as Recognized Consensus Standards.

Regarding 'Adoption level':
The federal rule from Austria above correctly states that all major vendors do support this standard already (which is not fully correct but we are fairly close) and the number of devices already sending 11073 data is in the area of a few millions every day.


Do you think the Pacemaker industry should be more active in Continua as well? So far, I see this more as a place for external devices.

 

Submitted by mkirwan@pchall… on 2017-11-20

Section I – V Representing Patient Vital Signs

In the connected health system, the device status info and context info are useful to ensure safe and efficient operation and maintenance of the system.

Such info is not the vital sign itself, but is necessary ingredient for the infrastructure when conveying vital sign data from one end to another.

It may also be leveraged by the platform operator or service provider to remotely manage and/or configure the user devices. Therefore we suggest ONC ISA to include such type of data, at least as an Annex.

ISO/1EEE 11073 Nomenclature is a data set which contains such info. For example: the generic device status, the CGM device status, the operational and therapy conditions of insulin pump, etc.

Submitted by gdixon on 2018-09-12

Vital Sign Definition Enhancements Needed for CCDA

Current HL7 CDA R2.1 IG: Transition of Care Vital Signs Value Set: Vital Sign Result Type urn:oid:2.16.840.1.113883.3.88.12.80.62   This is a finite group of vital signs. Current CCDA IG has not defined inclusion of device information related to vital signs, this will need to be resolved if transport is to include CCDA

Depending on the transition of care environment and workflow there is a higher percentage of vital signs that will not include device information and the majority of the “vital signs” in defined Vital Sign Result Type are not readily supported by devices.

With inclusion of device support it is implied that the Vital Sign Result Type list should be expanded beyond basic vital signs, that will need to be specified. 

Vital signs should optionally contain supporting information.  E.g. “8310-5 Body Temperature” should have supporting collection information. Oral, Tympanic, Rectal, Etc. This is clinically valuable, it needs to be defined in implementation guide. 

ISO/IEEE 11073 Health informatics - Medical / health device communication standards should remain not federally required if there is a cost involved.

Submitted by cmcdonald on 2018-10-01

LOINC and IEEE have an…

LOINC and IEEE have an agreement and the IEEE codes are linked to the LOINC code for vitals (and many other things but FHIR and HL7 V2 argue that the LOINC code should be the code sent is the message). 

Should not be proposing two different code systems for the same purpose and it will break interoperability.