The facility address is captured with every encounter and easy to add to the APIs. No feedback is needed for this Data Element.

UDI

FDA introduce UDI 10 years ago. The US Core Implantable Device Pofile captures UDI data for implants. Hospitals may be using it to collect and report implantable device data to the NHSN. This proposal expands it to capture and exchange on all devices such as:

- Sterilization trays 

- Hearing aids 

- Continuous glucose monitors (CGMs)

This is a new burden on end users to capture and exchange information that may not be relevant to patient care. As far as we know, there are no concomitant EHR capture requirements.

ASTP needs to address these considerations to ensure the successful implementation of UDI data in interoperable health IT systems.

Portable Medical Order

The Portable Medical Order data element is defined as a "Provider-authored request for end-of-life or life-sustaining care for a person who has a serious life-limiting medical condition. This definition is ambiguous in the context of an order. The term "Portable Medical Order" commonly means a POLST/MOLST (Physician Orders for Life-Sustaining Treatment) form and these are typically clinical Documents (e.g., a paper document or a PDF) However in this context it may be specific request to create a POLST document in which case the existing US Core ServiceRequest Profile could be used although the potential requirement for signatures might be a significant burden for implementers.

ASTP needs to clarify whether this data element is a document type or a physician order to produce a "portable medical order" If it is the former then reclassify it as a type of Clinical Note. If it is the latter then clarify the definition.

Care Plan

CarePlan's scope and definition seem to align with the US Core CarePlan Profile. No feedback is needed for this Data Element.

Date of Onset

Although the US Core Condition supports the "Date of Onset", it is conflated with the USCDI Data Element "Date of Diagnosis" and is not captured and exchanged uniformly by systems. ASTP needs to acknowledge this and possibly merge these two data elements?

Family health history

This Data element is listed under the Problems data class with links to terminology, implying that the intent is to use a codes to meet this data exchange requirement.

see §70.315(a)(12)

(12) Family health history. Enable a user to record, change, and access a patient's family health history in accordance with the familial concepts or expressions included in, at a minimum, the version of the standard in § 170.207(a)(1). (Family Health History certification criterion: ONC's intent with “familial concepts and expressions” is to focus on the first degree relative’s diagnosis.)

Based on this interpretation, no feedback is needed for this Data Element.