Representing Patient Vital Signs

Continuous Glucose Monitoring

Please provide details for the implementation of continuous glucose monitoring data in the Vital Signs data elements.  Would like to know when to expect this data element and which version of USCDI to expect this to be released.  Would also require the data element type (expecting integer) including precision (expecting 0).

Preserving Clinical Context

General Comments: USCDI specifies lots of clinical data classes and data elements

• Resolving to myriad de-coupled fragments
• With vanishingly little focus on:
  • Clinical context and vital inter-relationships, e.g., between problems, diagnoses, complaints, symptoms, encounters, history and physical findings, allergies, medications, vaccinations, assessments, goals/objectives, clinical decisions, orders, results, diagnostic procedures, interventions, observations, treatments/therapies, referrals, consults, outcomes, protocols, care plans and status...
  • Elements and context + purpose of capture:  e.g., blood pressure, its measurement (systolic, diastolic), its unit of measure (mm/Hg), its reason for capture, its context of capture (sampling site, sampling method, patient position, at rest/during/post exercise...

It is crucial to consider, determine and resolve how clinical content and context are bound together and preserved in USCDI.  The ultimate end user (often a clinician) must be able to readily discern context and inter-relationships – otherwise USCDI places an undue (and often unresolvable) burden on this user.  Only the source EHR/HIT system can structure clinical content and context properly.  Once data is stuffed into the USCDI framework and related exchange artifact (e.g., FHIR resources) this opportunity is forever lost.

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. 

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.

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.

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.  

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

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…