Contextual information that provides supporting details for healthcare data.

Data Element
Anatomic Localization
Submitted By: Matthew Molenda / Anatomy Mapper OpCo
Data Element Information
Data Element Description A standardized, codeable representation of a patient body site (anatomic location) used to localize, document, and track clinical findings, procedures, specimens, imaging findings, and orders; includes a canonical, visual-anchored site identifier and explicit laterality.
Rationale for Separate Consideration Anatomic Localization is related to existing contextual and location-oriented elements in USCDI, most notably Specimen Source Site. However, it should be considered separately because it represents a distinct, reusable clinical concept: where on the patient’s body a finding, procedure, specimen, order, or event applies.

Current USCDI elements capture body site only in narrow, workflow-specific ways. For example, "Specimen Source Site" applies specifically to laboratory workflows, while "Location of Procedure" has been used to refer to the healthcare service location or setting where the procedure occurred rather than the anatomical body site. A general-purpose Anatomic Localization element would provide a reusable and interoperable mechanism to represent body site consistently across multiple USCDI data classes. Note: "Anatomic Location" would be an alternate Data Element Name, but "Localization" may have less likelihood of confusion with other data elements like "Location of Procedure"
Use Case Description(s)
Use Case Description Anatomic Localization is needed to support standardized documentation, exchange, and interpretation of body site information across clinical workflows. In many scenarios, it is not sufficient to know that a procedure, order, test, finding, or event occurred. It is also necessary to know where on the patient’s body it occurred in a standardized, machine-readable way.

Examples include:

documenting the body site of a procedure or procedure note,
specifying the target of a diagnostic imaging order,
identifying the body site of a clinical finding or problem,
associating a laboratory specimen with its source site,
documenting the anatomical location relevant to an adverse event,
supporting referral orders and clinical notes where body site is clinically significant.

A canonical, standardized anatomic localization/location would improve routing, scheduling, documentation clarity, result interpretation, referral workflows, longitudinal tracking, quality measurement, and interoperability.

Additional Use Case Description: Anatomic Localization is particularly valuable where existing applicable vocabulary standards are broad, overlapping, or inconsistently granular. In these situations, standardized, unambiguous, and machine-readable body-site data can distinguish between otherwise similar procedures, findings, orders, and reports.

For example:

the same type of procedure may occur at very different body sites,
the same diagnosis may have different significance depending on body site and laterality,
imaging orders often require explicit anatomical targeting,
specimen interpretation benefits from knowing the source site.

A reusable Anatomic Localization element would support both coarse-grained and fine-grained anatomical specificity depending on clinical workflow and implementation feasibility.
Estimate the breadth of applicability of the use case(s) for this data element Anatomic Localization applies broadly across most care settings and specialties because body site is a fundamental clinical attribute relevant to procedures, orders, imaging, laboratory workflows, clinical findings, documentation, and patient safety. It is applicable in ambulatory care, hospital care, emergency care, surgical workflows, specialty care, imaging, pathology, and laboratory settings.
Link to use case project page https://edu.anatomymapper.com/case-studies
Use Case Description Anatomic Localization also has broader applicability beyond the primary documentation and exchange use cases. Standardized, unambiguous, and machine-readable body-site data would support quality measurement and registries, public health and surveillance, clinical decision support, referral management, imaging interoperability, patient-facing summaries and care coordination, and research and analytics. These use cases are relevant because many downstream activities depend not only on knowing that a finding, order, procedure, or event occurred, but also on knowing where on the patient’' body it applies.
Estimate the breadth of applicability of the use case(s) for this data element This data element would be relevant to a large national cross-section of healthcare stakeholders, including hospitals, ambulatory practices, health systems, imaging centers, laboratories, specialty practices, EHR developers, HIE participants, public health agencies, registries, payers, researchers, and patients accessing their data through certified health IT. Because Anatomic Localization applies across multiple USCDI data classes and workflows, the number of affected stakeholders would reasonably be in the tens of thousands of provider organizations and health IT entities, with downstream impact on millions of patients whose records include procedures, findings, orders, imaging, laboratory specimens, or other site-specific clinical data.
ONC Priority
  • Address public health interoperability needs of reporting, investigation, and emergency response
Maturity of Use and Technical Specifications for Data Element
Applicable Standard(s) Anatomy Mapper terminology is a standardized terminology and codeable concept set for surface anatomy that is spatially linked to visual definitions. SNOMED CT is already an applicable vocabulary standard in USCDI, but (especially for surface anatomy) it includes overlapping or ambiguous concepts where multiple concepts describe the same anatomic region or body structure. Anatomy Mapper terminology provides a canonical spatial and semantic reference for surface anatomy while supporting interoperable use of codeable concepts.
https://anatomymapper.com/Terms/AMID
Additional Specifications N/A
Current Use (Level 1) Captured, stored, or accessed in at least one production EHR or HIT module
Extent of exchange (Level 0) Limited environments, such as connectathons or pilots
Supporting Artifacts Anatomy Mapper EDU version is already in clinical use where users in multiple EHR platforms label their health findings with the the standardized, visual labeling tools provided. A FHIR IG is proposed but not yet complete at time of writing.
https://edu.anatomymapper.com
Potential Challenges
Restrictions on Standardization (e.g. proprietary code) Anatomy Mapper OpCo looks forward to working with ASTP/ONC and the USCDI process to help define a practical implementation floor and associated usage guidance for Anatomic Localization. Anatomy Mapper terminology is an external terminology. Its AMcode codeable concepts, hierarchical relationships, and visual definitions are proprietary in order to maintain a canonical spatial and semantic source of truth, together with consistent visual references for each term and composed description. This proprietary structure supports unambiguous anatomical representation, but it may limit full open redistribution of the complete terminology. Proprietary terminology should not preclude inclusion of a high-value reusable data element in USCDI, particularly where the data element itself can be standardized and the applicable vocabulary standard can be transparently identified and appropriately licensed. A practical approach would be to support a clearly defined implementation floor for interoperability, with broader or more detailed proprietary concepts available where licensing permits.
Restrictions on Use (e.g. licensing, user fees) Use of the data element itself should not be restricted. Anatomy Mapper terminology may be one Applicable Vocabulary Standard for this data element, initially for representation of surface and external anatomy. Anatomy Mapper’s EDU version provides free access to a visual label generator, along with a free license for clinical users to use generated outputs, including semantic descriptions and composed codeable concepts, in a patient's chart. Separate commercial licenses are required for vendors and other organizations seeking to use Anatomy Mapper in direct integrations, analytics, automated coding, AI workflows, visualization, summarization, targeting, or other scaled commercial uses.
Privacy and Security Concerns None beyond standard clinical data protections.
Estimate of Overall Burden Moderate burden overall. The burden to implement in direct clinical care is relatively low because body-site information is already routinely documented, and structured body-site capture is already used in production clinical workflows across multiple EHRs. The primary implementation work involves standardizing representation, mapping existing free-text or local site fields, and incorporating structured body-site capture into exchange workflows. Burden is higher for vendors and broader health IT environments that wish to fully integrate Anatomic Localization into EHRs, imaging systems, laboratory systems, interoperability APIs, analytics, or decision support. A baseline implementation floor would likely be feasible with modest effort.
Other Implementation Challenges Other implementation challenges include variability in how body-site information is currently documented across specialties and systems, including free text, local abbreviations, and workflow-specific fields. Existing standards and terminologies also vary in granularity, hierarchy, overlap, precision, and laterality support. Some workflows require only coarse anatomical representation, while others optimally require fine-grained specificity. There may also be ambiguity between anatomical body site and service or facility location in some implementations, particularly in procedural workflows. Clear implementation guidance would help distinguish these concepts and promote consistent adoption across settings.
ONC Evaluation Details
Each submitted Data Element has been evaluated based on the following 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
Criterion #1
Maturity - Current Standards		 Level 0 - Data element is not represented by a terminology standard or SDO-balloted technical specification or implementation guide.
Criterion #2
Maturity - Current Use 		Level 1 - Data element is captured, stored, or accessed in at least one production EHR or HIT module.
Criterion #3
Maturity - Current Exchange		 Level 0 - Data element is electronically exchanged in limited environments, such as connectathons or pilots.
Criterion #4
Use Case(s) - Breadth of Applicability		 Level 0 - Use cases apply to a limited number of care settings or specialties, or data element represents a specialization of other, more general data elements.

Comment

Log in or register to post comments

FormGuide

Help

1. Optional: Background Text / Cover Letter

The "Optional Background Text / Cover Letter" field provides space for additional context or introductory information related to your comment.

If you wish to provide context, explanation, or an introduction to your comment, enter this information in the field labeled "Optional Background Text / Cover Letter." This is entirely optional and is most useful when submitting multiple related comments or when additional background would help reviewers understand your feedback.

If you are only commenting on a single data class or element, you may leave this field blank.

2. Select the Data Class

To specify which data class your comment addresses:

  1. In the "Data Class" drop-down menu, select the appropriate data class you want to comment on.
  2. If you are providing a general comment that is not specific to a data element, select "General" from the options. Comments with this designation will be displayed on the USCDI landing page.
  3. Note that the Data Class field will automatically populate based on your current location in the platform:
    1. If you are on a data class page, the field will be set to that specific data class
    2. If you are on a data element page, the corresponding data class will be pre-selected
       

3. Select the Data Element

To specify which data element your comment addresses:

  1. In the "Data Element" drop-down menu, select the specific data element you want to comment on.
  2. The drop-down menu will display only the elements available under the data class you selected in the previous step.
  3. You can use the search function within the drop-down to quickly locate a specific data element.
  4. If you are commenting on the data class itself rather than a specific element, you may leave this field blank.

Note: Comments on a specific data element will appear on the respective data element page, while comments on a data class (without a specific element selected) will appear on the landing page for that data class.
 

Data Class and Data Element

Fig 1 The "Data Class" and "Data Element" dropdown menus allow users to specify the exact content they wish to comment on.

4. Optional: Propose New Data Class or Element

If you cannot find the appropriate data class or element for your comment:

  1. Instead of clicking the "Comment On An Existing Data Class Or Element" button, click the adjacent button labeled "Propose a New Data Class or Data Element."
  2. This will redirect you to the ONDEC (ONC New Data Element and Class) Submission System.
  3. In the ONDEC system, follow the provided instructions to submit your proposal for a new data class or element.
  4. Once your proposal is submitted through ONDEC, it will be reviewed separately from the commenting process.
Propose New Data Class or Element

Fig 2 The "Propose a New Data Class or Data Element" button redirects users to the ONDEC Submission System for proposing new data elements not currently available in the system.

5. Complete the Comment Form

Fill out the required fields in the comment form:

Subject: Enter a brief, descriptive title that summarizes your comment. This helps reviewers quickly understand the nature of your feedback.

Comment: In this field, provide the full details of your comment or feedback. Be as clear and specific as possible about your suggestions, concerns, or observations. Include any relevant details that support your position.

6. Optional: Add Additional Comments

If you need to comment on multiple data classes or elements:

  1. After completing your first comment, click the link labeled "Comment on another data element" at the bottom of the form.
  2. A new comment section will appear, allowing you to enter details for your additional comment.
  3. For each additional comment, you must select the appropriate data class and data element from the drop-down menus.
  4. Complete the Subject and Comment fields for your additional comment.
  5. Repeat this process for each additional comment you wish to submit.

Fig 3 The "Comment on another data element" link enables users to create multiple comments addressing different elements within a single submission.

7. Optional: Upload Supporting Files

The platform allows you to upload supporting documentation to enhance your comment:

  • Locate the "File Upload" section at the bottom of the comment form.
  • Click to upload any files (such as PDFs or documents) that provide additional context, evidence, or clarification for your comment.

Important: If you have already entered your comments using the form fields, there is no need to upload duplicate content in PDF format. The file upload feature is intended for supplementary materials only. Please avoid uploading files that contain the same information already provided in your comment text.

Upload Supporting Files

Fig 4 The "File Upload" section permits users to attach supporting documentation that supplements their written comments.

8. Optional: Save and Exit

If you need to pause your work and return to complete your comment later:

  1. Click the "Save and Exit" button at the bottom of the form.
  2. Your comment will be saved as a draft that you can access and complete later.
  3. When you return to the platform, you will see a red triangle with an exclamation mark next to the “Return to saved Comment” button, indicating that you have saved comments in draft status.
  4. Click this button to continue working on your draft.
  5. You will be taken to a review page where you can:
    1. Select "Submit Comment" to officially submit your feedback.
    2. Click "Edit" to return to the comment form and make changes
    3. Select "Discard Draft" to delete the saved draft and start fresh

Fig 5 A red triangle with exclamation mark indicator appears next to the “Return to saved Comment” button when draft comments are saved in the system.

9. Review and Submit

Once you have completed your comment:

  1. Click the "Review and Submit" button at the bottom of the form.
  2. This will take you to a review screen displaying your comment(s) in full.
  3. Review all information for accuracy and completeness.
  4. On this review screen, you have three options: 
    1. Click "Submit Comment" to officially submit your feedback
    2. Click "Edit" to return to the comment form and make changes
    3. Click "Discard Draft" to delete the comment and start fresh
  5. The review screen also includes a "Print" button that allows you to create a printed copy of your comments for your records. 
  6. If you choose to submit, your comment will be recorded in the system and made available for review by the appropriate stakeholders.
Review and Submit

Fig 6 The review screen allows users to verify comment content and make any necessary modifications before final submission.

USCDI Comments

Close

Add a New Comment

Review comment and Submit

Edit
Comment #1
PDF, Doc, Docx
Max Size : 10 MB