| Submitted By: KarenP-SSA / Social Security Administration (SSA) | |
|---|---|
| Data Element Information | |
| Rationale for Separate Consideration | This expands the instances of clinical notes available on the USCDI roadmap. |
| Use Case Description(s) | |
| Use Case Description | To assist with disability determination, SSA sends an electronic request and a patient authorization to the healthcare provider’s system via national health data exchange networks. Information is returned within seconds or minutes, rather than the days or weeks it may take when manual methods of requesting medical records are used. This automation—when sufficient details are provided via the full complement of clinical notes—can result in a significant reduction in the time it takes to make a disability determination, which produces: 1) Faster disability claim determination and quicker benefit payments to patients; 2) Labor savings and payments to providers; 3) Cost efficiencies for US taxpayers. This request to expand the set of Notes included in USCDI includes: 1) Constrained coding for each (like specified for most of the V1 USCDI Notes); 2) Constraints on where each should appear. |
| Estimated number of stakeholders capturing, accessing using or exchanging | Today, SSA requests about 2 million medical records electronically (15-20 million total) from almost 500,000 providers on behalf of 3 million patients annually. The agency plans annual increases in the amount of medical records received electronically. |
| Link to use case project page | https://github.com/SSAgov/HealthIT |
| Supporting Attachments |
Suggested LOINC codes and placement for SSA USCDI V2 Clinical Notes proposal final.pdf |
| Use Case Description | Most health information exchange use cases involve clinical notes, and “notes” are indeed included in much of that exchange, but this information is scattered throughout clinical documents—some as well-defined “clinical notes and others as observations “sections” in CDA and various Resource types in FHIR. Many “notes” use using coding from a grab bag of available values for coding the same information. Understandably, standardizing functionality around this USCDI addition will not happen overnight, but (most critically) it will establish the roadmap for standardizing the electronic health information (EHI) exchanged in order to increase the effectiveness of this information for clinicians, patients, payers and other stakeholders. • Key Takeaway: This expanded list of USCDI Clinical Notes, along with constraints on their coding and placement, defines the roadmap for implementers to use as they prioritize support of additional clinical notes. |
| Estimated number of stakeholders capturing, accessing using or exchanging | Health records are exchanged between millions of providers (and, increasingly, payers) through dozens of health information exchanges (HIEs) in support of tens of millions of patients every year. |
| Healthcare Aims |
|
| Maturity of Use and Technical Specifications for Data Element | |
| Applicable Standard(s) | LOINC—although we would like to see the set of codes constrained as suggested above. In Data Element Description above, we have the suggested LOINC code (showing also the Long Common Name) for each Note in our list. Such constraints are needed in order to allow for semantic interoperability. https://search.loinc.org/searchLOINC/search.zul?query=Note |
| Additional Specifications | HL7 FHIR® US Core Implementation Guide: Clinical Notes Guidance https://build.fhir.org/ig/HL7/US-Core-R4/clinical-notes-guidance.html We advocate following the core guidance in this guide: “All of [USCDI V1] clinical notes SHALL be exposed via DocumentReference. This requirement is necessary because some systems scan lab reports and do not store them in the DiagnosticReport resource. See FHIR Resources to Exchange Clinical Notes (https://build.fhir.org/ig/HL7/US-Core-R4/clinical-notes-guidance.html#fhir-resources-to-exchange-clinical-notes) for more detail.” and: “In order to enable consistent access to scanned narrative-only clinical reports the Argonaut Clinical Note Server SHALL expose these reports through both DiagnosticReport and DocumentReference by representing the same attachment URL using the corresponding elements listed below. Exposing the content in this manner guarantees the client will receive all the clinical information available for a patient and can easily identify the duplicate data. • DocumentReference.content.attachment.url • DiagnosticReport.presentedForm.url” |
| Current Use | This data element has been used at scale between multiple different production environments to support the majority of anticipated stakeholders |
| Supporting Artifacts |
Many EHR systems support many varieties of Clinical Notes—albeit using multiple variations of the currently unconstraint coding. Adding the additional notes we are requesting—along with the constrained coding--to USCDI will provide the industry with guidance on those constraints and create a roadmap for standardization of this information. |
| Number of organizations/individuals with which this data element has been electronically exchanged | 5 or more. This data element has been tested at scale between multiple different production environments to support the majority of anticipated stakeholders. |
| Supporting Artifacts |
Today, SSA receives about 2 million medical records annually from almost 200 partner organizations. The agency plans to continue to increase the amount of medical records received electronically. The ability of those organizations to provide this information is a fundamental screening requirement for participation in our program. |
| Potential Challenges | |
| Restrictions on Standardization (e.g. proprietary code) | None |
| Restrictions on Use (e.g. licensing, user fees) | None |
| Privacy and Security Concerns | None |
| Estimate of Overall Burden | Implementation burden should be light for implementers already supporting the production and coding of clinical notes. This is adding and/or refining instances and standardizing the coding of existing clinical notes functionality, not creating net-new functionality. |
| ONC Evaluation Details Each submitted Data Element has been evaluated based on the following 4 criteria. The overall Level classification is a composite of the maturity based on these individual criteria. This information can be used to identify areas that require additional work to raise the overall classification level and consideration for inclusion in future versions of USCDI |
|
|---|---|
| Maturity – Standards/Technical Specifications | Comment Level - May be represented by a vocabulary standard or an element of a published technical specification. |
| Maturity - Current Use | Level 2 - Used at scale in more than 2 different production environments |
| Maturity - Current Exchange | Level 2 - Demonstrates exchange between 4 or more organizations with different EHR/HIT systems |
| Breadth of Applicability - # Stakeholders Impacted | Level 2 - Used by a majority of patients, providers or events requiring its use |
Comment