USCDI Draft-V7 Feedback
Submission completed:
Hello Riki Merrick
Thank you for your comment on USCDI. Click the link(s) below to view the comment on the USCDI page
https://isp.healthit.gov/user/2351#comment-14680
https://isp.healthit.gov/user/2351#comment-14681
https://isp.healthit.gov/user/2351#comment-14682
https://isp.healthit.gov/user/2351#comment-14683
https://isp.healthit.gov/user/2351#comment-14684
https://isp.healthit.gov/user/2351#comment-14685
https://isp.healthit.gov/user/2351#comment-14686
https://isp.healthit.gov/user/2351#comment-14687
https://isp.healthit.gov/user/2351#comment-14688
Thank You,
ISA Team
Proposed wording to approve:
1. Overarching Comments:
SHIELD appreciates the role that USCDI plays in standardizing health data for interoperability. However, the use of classes for grouping of the data elements results in a fragmentation of data elements that are applicable to particular use cases, and might “hide” important elements in classes not familiar to the implementers of the use case. At least for the clinical elements SHIELD suggests to remove the classes and provide a listing of the elements alphabetically. Then, for example in USCDI+, each use case or speciality could identify the USCDI elements that are required to preserve the clinical context. Specifically for the laboratory data use case the fragmentation of required elements for orders and results across 7 of these classes leads to different interpretations of the requirements. SHIELD participants have noted that without a complete set of laboratory data, they are unable to validate and therefore integrate the laboratory data that is currently flowing into care processes and analytics, resulting in low-yield, low quality data exchanges.
The high level of USCDI element definitions leads to inconsistencies across the industry when individual health and laboratory entities determine individually how to fill in the gaps. The lack of a coherent data model is still a barrier to end to end laboratory interoperability and SHIELD strongly encourages ASTP/ONC to consider more formally defining a data model for the current lab related data elements, including more formal vocabulary bindings. By providing a more defined data model, boundaries and relationships between similar elements such as Device Type vs UDI, Encounter vs Appointment; Procedures vs Orders; and Events vs Outcomes would become clearer. This would add great value by improving laboratory data interoperability and could be an opportunity to onboard Laboratory Information Systems into FHIR data exchange with standardized source data. SHIELD would be excited to offer its industry, informatics and healthcare expertise to any effort to build out a shared laboratory data model with other laboratory interoperability stakeholders.
SHIELD suggests the support for synonyms for USCDI data elements, to enable specialities to utilize the names familiar in their domain to enable proper identification of a data element; for example while the usage notes include the synoym of Specimen Collection Date/Time, a laboratorian may not even look at the element because of the non-intuitive name Performance Time.
SHIELD suggests to update to the latest available version at time of publication of V7 for all called out coding systems/terminologies.
2. Performance Time (under new Healthcare Information Attributes class): !!!NEW CONTENT!!!
SHIELD supports the inclusion of this data element, as it is commonly exchanged and provides the temporal context for all the use cases, where it is used. However the name and definition of this data element are not intuitive for the lab result use case - in HL7 we call this data element “clinically relevant time” - for labs that matches the Laboratory / Specimen collection date/time (Definition: Date/time when clinical specimen was collected from subject patient. This is the clinically relevant date time of an observation when a specimen is collected for a test.) However, we feel that this element should be kept separate from the Specimen Collection Date/Time. For laboratory data there are several dates that are important:
Specimen Collection Date/Time (start and end time)
Specimen Received Date/Time
Test Result Performance Date/Time
Test Result Released Date/Time
Suggestions:
Proposed new name: “Clinically Relevant Date/TimePerformance Date/Time”
Proposed new definition: “Clinically relevant date and/or time a care activity is performed; for laboratory tests, this is the date/time the specimen is collected.” Update the example sentence to: “Examples include but are not limited to vaccine and medication administration date/times, surgery start date/time, date/time ultrasound performed, or date/time laboratory test performed.”
Suggest to support synonmys for USCDI data elements, and one of these should be “Specimen Collection Date/Time”
In addition we need to elevate the level 0 element: Specimen Collection Date/Time, which provides the biologically relevant time for in vivo test for the clinical context.
Also important is the Date/Time each result is released, which makes it available for use (e.g. in clinical care, for surveillance)
USE THIS FOR VOTING for #2:
SHIELD supports the inclusion of this data element, however the current definition leaves room for interpretation depending on the type of care activity being documented and could be interpreted differently across different domains.
For in-vivo care activities Performance Date/Time also represents the temporal context of the patient’s state, i.e. the physiologically or clinically relevant date/ time, but for in-vitro activities like laboratory testing performance time, i.e. the date/time the results are created is different from the physiologically or clinically relevant date/ time, which in this case is the specimen collection date/time. So we need to decide what this element is expected to represent.
#A If the intent is to represent when the activity occurred then SHIELD suggests:
Update the name to “Performance Date/Time” with the existing definition
Update the Note to: “Examples include but are not limited to vaccine and medication administration date/times, surgery date/times, date/time ultrasound performed or laboratory test results are generated by an instrument or recorded by the laboratorian.”
In addition to this element, to ensure the capture of the biologically relevant time for in-vitro tests for the clinical context of the patient’s state the current level 0 element Specimen Collection Date/Time must be elevated into V7, because it is a required data element per CLIA for a test request (https://www.ecfr.gov/current/title-42/chapter-IV/subchapter-G/part-493#p-493.1241(c)(6) ). Also this element has been exchanged in HL7 V2 messages as OBR-7 (Observation Date/Time for the start date/time) and SPM-17 (Specimen Collection Date/Time covering start and end date/time with the date range datatype) and is represented in FHIR Specimen.collection.collectedDate/time or Specimen.collection.collectedPeriod).
Guidance should be provided that this element captures the start and end date/times (periods) for longer care activities. If that is not the intent, then update the name to “Performance Start Date/Time” and add another data element to allow recording of the end of a care activity named “Performance End Date/Time” and adjust the definitions accordingly.
#B If the intent is to represent the date/time important to understand the patient’s clinical state, then SHIELD suggests:
Update the name to: “Biologically Relevant Date/Time” or “Patient’s State Defining Date/Time” or “Clinically Relevant Date/Time”
Update the definition to: “Date/time that provides the temporal context about the patient’s state (physiological or psychological) at the time the care activity takes place or provides diagnostic insights about.”
Update the Note to: “For in-vivo care activities like vaccine and medication administration, surgery, ultrasound performed, vital signs documentation as well a health status assessments this date/time is equivalent to the performance date/time. For in-vitro care activities like laboratory testing, this is the date/time of specimen collection.”
To ensure the capture the performance date/time of the lab test add the new element “Laboratory Test Performed Date/Time" with the definition: "Date (and optionally time) when the instrument or technologist (for manual testing) generated the result.” with the Usage Note: "This is the date/time when the results are generated by an instrument or recorded by the laboratory technologist."
Guidance should be provided that this element captures the start and end date/times (periods) for longer care activities. If that is not the intent, then update the name to “Biologically Relevant Start Date/Time” and add another data element to allow recording of the end of a care activity named “Biologically Relevant End Date/Time” and adjust the definitions accordingly.
3. Diagnostic Report Date (under new Healthcare Information Attributes class):
SHIELD supports the inclusion of this commonly exchanged data element for many use cases; in the lab data exchange use case it corresponds to the CLIA requirement of "(3) The test report date." from 42 CFR 493.1291. While the CLIA regulation identifies the element soley as date, there are situations, where including the time in addition to the date is important, as is evidenced by the definition of this element, so SHIELD suggests to update the name to incorporate that.
Suggestions:
Proposed updated Name: Diagnostic Report Date/Time
Proposed new Usage Note: “This element will change every time a new version of the report is released, covering preliminary, final, corrected, amended or addended reports. For each version the timestamp should be preserved.”
4. Specimen Condition
SHIELD supports the renaming of this element, as the revised name more clearly conveys that it characterizes the specimen itself and may inform clinical decision‑making. When multiple results and their values are generated from analysis of the same specimen the specimen condition may impact clinical decision making on a result level basis. In addition, the laboratory evaluates the specimen conditon for each ordered test which could result in a reject reason for performing a test.
5. Device Type
SHIELD supports the inclusion of this data element, but we would welcome clarification how this is intended to be used in conjunction with the Unique Device Identifier element. This also would benefit from a more crisp scope around which devices are expected to be tracked for laboratory result values and suggest to initially focus on instruments and test kits/reagents, not controls, calibrators or other consumables.
We suggest narrowing the scope of SNOMED CT to descendenants of 272181003 |Clinical equipment and/or device (physical object) and add the follwoing Usage Note: “This element supports categorization of medical devices, while the UDI element identifies the specific medical device used for that patient, procedure, performed lab tests.”
6. Laboratory Order:
SHIELD suggests ASTP/ONC clarify the scope of this data element as the current definition is not clear enough:
Given that ASTP/ONC associates LOINC as the required vocabulary for Laboratory Orders, most likely the data element targeted here is “Ordered Test” which should cover both the code (drawn from LOINC and available as USCDI+ Public Health Lab Use Case Laboratory Test/Panel Code as well as the display name for that test in the Laboratory Compendium (CLIA requirement) compared to the CLIA defintion of what the test request needs to include (https://www.ecfr.gov/current/title-42/section-493.1241 ).
SHIELD supports the use of LOINC when an appropriate code is available for Laboratory Orders whenever they are being communicated externally and should cover all orders; the initial order, individual occurrences of a multi-occurrence order, individual tests from a larger panel ordered to a reference laboratory, reflex, etc.
In general the Laboratory Order as currently defined requires more data elements to provide the needed information to the laboratory to properly perform their testing; from a regulatory perspective these are called out in CLIA https://www.ecfr.gov/current/title-42/section-493.1241:
The laboratory must ensure the test requisition solicits the following information:
(1) The name and address or other suitable identifiers of the authorized person requesting the test and, if appropriate, the individual responsible for using the test results, or the name and address of the laboratory submitting the specimen, including, as applicable, a contact person to enable the reporting of imminently life threatening laboratory results or panic or alert values. = USCDI elements: Care Team Member Name, Care Team Member Location, Care Team Member Telecom
(2) The patient's name or unique patient identifier. = USDCI elements: Patient First Name, Patient Last Name, Patient Middle Name (Initial), Patient Suffix, Patient Identifier
(3) The sex and age or date of birth of the patient. = USCDI elements: Patient Sex, Patient Date of Birth
(4) The test(s) to be performed. = USCDI element - this one
(5) The source of the specimen, when appropriate. = USCDI element: Specimen Type and Specimen Source Site
(6) The date and, if appropriate, time of specimen collection. = USCDI element: Perfomance Time
(7) For Pap smears, the patient's last menstrual period, and indication of whether the patient had a previous abnormal report, treatment, or biopsy. = no explict USCDI elements
(8) Any additional information relevant and necessary for a specific test to ensure accurate and timely testing and reporting of results, including interpretation, if applicable. = no explict USCDI elements
SHIELD supports the inclusion of this data element, but notes that clarification is needed if this covers cancelations of orders as well as providing reasons why results could not be obtained. There are a variety of reasons why tests are not performed, in some cases it may be due to the condition of a specimen. Other words that could be used to describe some of these situations are cancelation reason or specimen reject reason.
SHIELD suggests to update the usage note to state: "Usage note: Should be included with procedures, immunizations, medications, laboratory results and orders when they are not performed."
8. Adverse Event Class
SHIELD requests ASTP/ONC to clarify what kind of Adverse Events are covered with this class. Does it cover all of these: CLIA-certified laboratories reporting on laboratory-developed tests (LDTs)), Adverse event reporting as part of FDA post-market surveillance and NIH Clinical Trials?
9. Specimen Collection Method
SHIELD supports the inclusion of this data element as is supports the need for detail around the specimen, when it is not included in the precoordinated specimentype element, specifically since the laboratory does not need the full detail of the procedure used to collect the specimen. We suggest to use the same vocabulary used to describe the type of procedure, specifically SNOMED CT from the procedure hierarchy, to allow for post-coordination with the specimentype element, which also uses SNOMED CT.
Background links:
https://isp.healthit.gov/united-states-core-data-interoperability-uscdi#draft-uscdi-v7
Specific asks:
per Standards Bulletin 26-1:
Suggestions for improvement in the data classes or elements in Draft USCDI v7, including:
Data class and element definitions, usage notes, and examples; and
Examples of code systems used by health IT developers and implementers to communicate data element scope.
Should other existing Level 2 data elements be added to USCDI v7 instead of, or in addition to, those in Draft USCDI v7? If so, why?
What additional Level 2 data elements or USCDI+ data elements are appropriate for inclusion in USCDI v7, and why?
Are there significant barriers to development, implementation, or use of any of these data elements that warrant a change in the final version of USCDI v7?
ASTP/ONC seeks input on the Tobacco Use data element, including the optimal approach for representing this information in USCDI.
Specific focus in feedback on:
Provide comments on the name and definition of data elements
Identify other widely exchanged data elements that could be added - from other USCDI levels or USCDI+
Identify if the proposed data elements are being exchanged today between health IT systems
Show that these data elements are broadly usable across healthcare use cases and specialties
Draft Considerations:
Overarching Comment:
COPIED FROM V6 - IS THIS STILL APPLICABLE?: SHIELD appreciates the role that USCDI plays in standardizing health data for interoperability in the laboratory space. However, the high level of the USCDI guidance leads to inconsistencies across the industry when individual health and laboratory entities need to determine individually how to fill in the gaps. The lack of a coherent data model is still a barrier to end to end laboratory interoperability and many of the SHIELD participants have noted that without a complete set of laboratory data, they are unable to validate and therefore integrate the laboratory data that is currently flowing into care processes and analytics, resulting in low-yield, low quality data exchanges.
COPIED FROM V6 - IS THIS STILL APPLICABLE?: SHIELD strongly encourages ASTP/ONC to consider expanding USCDI’s laboratory data class to more formally define a data model for the current collection of data elements, including more formal vocabulary bindings. This would add great value by improving laboratory data interoperability and could be an opportunity to onboard Laboratory Information Systems into FHIR data exchange with standardized source data. SHIELD would be excited to offer its industry, informatics and healthcare expertise to any effort to build out a shared laboratory data model with other laboratory interoperability stakeholders.
New or modified data elements of interest to SHIELD
Laboratory Order: (COPIED FROM V6 and copied up)
SHIELD suggests ASTP/ONC clarify the scope of this data element as the current definition is not clear enough:
Given that ASTP/ONC associates LOINC as the required vocabulary for Laboratory Orders, most likely the data element targeted here is “Ordered Test” which should cover both the code (drawn from LOINC and available as USCDI+ Public Health Lab Use Case Laboratory Test/Panel Code as well as the display name for that test in the Laboratory Compendium (CLIA requirement) compared to the CLIA defintion of what the test request needs to include (https://www.ecfr.gov/current/title-42/section-493.1241 ).
SHIELD supports the use of LOINC when an appropriate code is available for Laboratory Orders whenever they are being communicated externally and should cover all orders; the initial order, individual occurrences of a multi-occurrence order, individual tests from a larger panel ordered to a reference laboratory, reflex, etc.
Medical Devices
no need to reiterate on the prevsiouly submitted comment: https://isp.healthit.gov/comment/14464
Unique Device Identifier:
no comment
Device Type (copied to the top already)
Pointing to SNOMED CT (no hierarchy listed, but potentially use descendenants of 272181003 |Clinical equipment and/or device (physical object); FHIR US Core uses https://hl7.org/fhir/R4/valueset-device-kind.html ) and provided some clarifying text in the class
GMDN will be included in SNOMED CT going forward, probably as its own extension:
Adverse Event Class
Unclear if this could include lab test results, or if this is only covering the condition change in a patient, as indicated by the SNOMED CT binding; Often Lab tests are used to determine that addvers events have happened. There are a lot of rules around what needs to be reported when an adverse event occurs both for FDA post-market surveillance and clinical trials.
Does this include adverse events based on clinical interventions after using lab results where the specimen condition was not optimal? Example: hemolized sample (is it medication related or due to use of too small a needle?)
Seems too hard to make a good connection between this to the lab tests, but we decided to ask the question about what adverse events are included.
Healthcare Information Attributes
This class was created to group some elements that are important for several domains. It is important to understand that these classes are not the only place where these need to be used.
Updated vocabulary (COPIED FROM V6):
SHIELD supports the use of LOINC when an appropriate code is available for Laboratory Orders whenever they are being communicated externally and should should cover all orders; the initial order, individual occurrences of a multi-occurrence order, individual tests from a larger panel ordered to a reference laboratory, reflex, etc.
SHIELD suggests to update to the latest available version at time of publication of V6 for all called out coding systems/terminologies.
Other Resources
HL7 OO:
Feedback collection: https://confluence.hl7.org/spaces/OO/pages/413056613/USCDI+V7+Draft+Feedback
CLIA element mapping to USCDI: https://confluence.hl7.org/spaces/OO/pages/256515226/US+-+CLIA+Elements+mapping+to+HL7+data+elements