Data used to categorize individuals for identification, records matching, and other purposes.

Data Element
Patient Social Security Number
Description

Records patient’s social security number.
Submitted By: Maria Michaels / CDC
Data Element Information
Use Case Description(s)
Use Case Description Monitoring disease and making decisions about public health threats depends on accessible and accurate data. EHRs are a data source with the potential to provide timely and relevant data beyond its use by health care providers. EHR data, if made more available for public health professionals and researchers, can lead to new innovations and more rapid disease detection.

Patient demographics such as patient medical record number, patient Medicare number, patient social security number are used to link health information to help address differences and gaps in care within specific populations. Patient gender identity, patient marital status, patient address use period, patient vital status, patient pregnancy status observation, patient birth place (City, Town, County Or Location Of Delivery), and patient country of birth are patient demographics utilized by multiple public health use cases to help assess characteristics within patient populations.

The public health use case(s) that support the adoption of these added elements are part of the Making EHR Data More Available for Research and Public Health (MedMorph) Reference Architecture. MedMorph has identified Cancer Reporting, Healthcare Surveys, Hepatitis C Reporting, electronic Initial Case Reporting (eICR), Multiple Chronic Conditions (MCC) eCare Plan, Message Mapping Guide (MMG) for COVID 19, PCORnet, Birth and Birth Defect Reporting use cases that support the adoption of these data elements. The goal of the MedMorph project is to develop and pilot a scalable and extensible standards-based reference architecture. This reference architecture will enable clinical data exchange with EHR systems and public health systems, specialized registries, national health care survey systems, and research information systems for multiple conditions.
Estimate the breadth of applicability of the use case(s) for this data element All 50 states participate in one or more of the public health surveillance use cases that exchange this data element.

All hospitals and physicians who diagnose or treat cancer are required to provide cancer related information to state cancer registries. Vital records reporting such as birth, fetal death and death are also required to be reported by each state. Every year there are approximately 2.8 million deaths and 3.7 million births in the United States.

Approximately 620,000 physicians in the US are active and have at least some component of ambulatory practice and thus are annually eligible to sampling and recruitment into the National Ambulatory Medical Care Survey (NAMCS), which samples from between 3,500 to 20,000 of these physicians annually. Presently each sampled physician submits one weeks' worth of patient encounters to NAMCS. Approximately 600 hospitals are in the National Hospital Care Survey (NHCS). 1/3 of that number are either in, or actively being recruited into, the EHR data submission mode for NHCS. NHCS is already receiving electronic CDA documents. When they reach their target of 200 hospitals submitting by this mode annually they will be receiving >1.2 million documents and sets including multiple sets of medication data annually. 

There were approximately 1,000,000 practicing physicians (as of 2020), approximately 120,000 certified physician assistants (as of 2019), and 290,000 licensed nurse practitioners (as of 2019). Most of these licensed clinicians interact with one of these public health use cases intermittently, annually. As of 2018, AHA reported 6,146 hospitals in the US experiencing 36,353,946 admissions. Almost all of those hospitals and at least half of the admissions interact with one or more of the public health use cases.

Additionally, public health reporting use cases are part of the Center for Medicare and Medicaid (CMS) Meaningful Use/Promoting Interoperability program adding on to the list of stakeholders under public health registries who capture electronic health information.

Supporting Links:
https://www.cdc.gov/csels/phio/making-ehr-data-more-available.html

https://www.cdc.gov/cancer/npcr/

https://www.cdc.gov/hepatitis/hcv/index.htm

https://www.cdc.gov/nchs/dhcs/nhcs_registry_landing.htm

https://www.cdc.gov/ecr/index.html

https://pcornet.org/

https://www.cdc.gov/nchs/nvss/deaths.htm

https://www.cdc.gov/nchs/nvss/births.htm
Link to use case project page https://www.cdc.gov/csels/phio/making-ehr-data-more-available.html https://www.cdc.gov/cancer/npcr/ https://www.cdc.gov/hepatitis/hcv/index.htm https://www.cdc.gov/nchs/dhcs/nhcs_registry_landing.htm https://www.cdc.gov/ecr/index.html
Supporting Attachments MedMorph-ChronicHepatitisCSurveillanceUseCase-DRAFT.pdf
MedMorph-CancerReportingUseCase-DRAFT.pdf
MedMorph-HealthCareSurveyReportingUseCase-DRAFT.pdf
Use Case Description The MedMorph project is being developed with the goal of generalizability to support many more public health and research use cases. Therefore, other public health and research use cases that use the MedMorph architecture will also benefit from adoption of this data element
Estimate the breadth of applicability of the use case(s) for this data element All 50 states participate in one or more of the public health surveillance use cases that exchange these data elements.

All hospitals and physicians who diagnose or treat cancer are required to provide cancer related information to state cancer registries. Vital records reporting such as birth, fetal death and death are also required to be reported by each state. Every year there are approximately 2.8 million deaths and 3.7 million births in the United States.

Approximately 620,000 physicians in the US are active and have at least some component of ambulatory practice and thus are annually eligible to sampling and recruitment into the National Ambulatory Medical Care Survey (NAMCS), which samples from between 3,500 to 20,000 of these physicians annually. Presently each sampled physician submits one weeks' worth of patient encounters to NAMCS. Approximately 600 hospitals are in the National Hospital Care Survey (NHCS). 1/3 of that number are either in, or actively being recruited into, the EHR data submission mode for NHCS. NHCS is already receiving electronic CDA documents. When they reach their target of 200 hospitals submitting by this mode annually they will be receiving >1.2 million documents and sets including multiple sets of medication data annually. 

There were approximately 1,000,000 practicing physicians (as of 2020), approximately 120,000 certified physician assistants (as of 2019), and 290,000 licensed nurse practitioners (as of 2019). Most of these licensed clinicians interact with one of these public health use cases intermittently, annually. As of 2018, AHA reported 6,146 hospitals in the US experiencing 36,353,946 admissions. Almost all of those hospitals and at least half of the admissions interact with one or more of the public health use cases.

Additionally, public health reporting use cases are part of the Center for Medicare and Medicaid (CMS) Meaningful Use/Promoting Interoperability program adding on to the list of stakeholders under public health registries who capture electronic health information.
Healthcare Aims
  • Improving patient experience of care (quality and/or satisfaction)
  • Improving the health of populations
  • Reducing the cost of care
  • Improving provider experience of care
Maturity of Use and Technical Specifications for Data Element
Applicable Standard(s) Social Security Administration: https://www.ssa.gov/history/ssn/geocard.html

Medicare Beneficiary Identifiers (MBIs): https://www.cms.gov/Medicare/New-Medicare-Card

PHIN VADS: Patient Marital Status: https://phinvads.cdc.gov/vads/ViewValueSet.action?id=DB54A32E-D583-4A24-BD9C-234B0C7BD0FD

Gender Identity - Gender harmony project definitions: https://www.jointcommission.org/-/media/deprecated-unorganized/imported-assets/tjc/system-folders/topics-library/lgbtfieldguidepdf.pdf?db=web&hash=224B46C31193399359B8113698971F26

FHIR patient extension: birthplace: http://hl7.org/fhir/R4/extension-patient-birthplace.html

FHIR patient address.period: http://hl7.org/fhir/us/core/StructureDefinition-us-core-patient.html

LOINC pregnancy status: https://loinc.org/82810-3/

Patient Vital Status: PHIN VADS, SNOMED-CT: https://phinvads.cdc.gov/vads/ViewValueSet.action?id=6EA795D5-5C5D-E511-81F8-0017A477041A
Patient vital status:CCDA uses Value Set - HealthStatus urn:oid:2.16.840.1.113883.1.11.20.12
Value Set Source: https://vsac.nlm.nih.gov/valueset/2.16.840.1.113883.1.11.20.12/expansion
https://www.ssa.gov/history/ssn/geocard.html https://www.cms.gov/Medicare/New-Medicare-Card https://phinvads.cdc.gov/vads/ViewValueSet.action?id=DB54A32E-D583-4A24-BD9C-234B0C7BD0FD
Additional Specifications HL7 CDA ® Release 2 Implementation Guide: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1, DSTU Release 1.1 – US Realm: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=398. SHALL for the following elements: Patient Address Use Period, Patient Birth Place, Patient Medical Record Number, Patient Social Security Number.

HL7 CDA® R2 Implementation Guide: National Health Care Surveys (NHCS), R1 STU Release 3 - US Realm: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=385

HL7 CDA® R2 Implementation Guide: Consolidated CDA Templates for Clinical Notes - US Realm: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=492. SHALL for the following elements: Patient Vital Status. SHOULD for the following elements: Patient Marital Status

HL7 FHIR® US Core Implementation Guide STU3 Release 3.1.1: https://www.hl7.org/fhir/us/core/index.html

HL7 FHIR US Core Patient: http://hl7.org/fhir/us/core/StructureDefinition-us-core-patient.html. MustSupport for the following elements: Patient Medical Record Number, Patient Medicare Number, Patient Social Security Number, Patient Address Use Period

HL7 FHIR® Implementation Guide: Electronic Case Reporting (eCR) - US Realm: http://hl7.org/fhir/us/ecr/STU1/Electronic_Initial_Case_Report_(eICR)_Transaction_and_Profiles.html

HL7 CDA® R2 Implementation Guide: Public Health Case Report, Release 2 - US Realm - the Electronic Initial Case Report (eICR): https://www.hl7.org/implement/standards/product_brief.cfm?product_id=436

IHE Quality, Research and Public Health Birth and Fetal Death Reporting-Enhanced (BFDR-E): https://www.ihe.net/uploadedFiles/Documents/QRPH/IHE_QRPH_Suppl_BFDR-E.pdf

HL7 FHIR Common Data Models Harmonization FHIR Implementation Guide http://hl7.org/fhir/us/cdmh/2019May/
Current Use In limited use in production environments
Supporting Artifacts Level 1 – in limited production (a few) environments, 1 or 2 different EHR/HIT systems.

eCase Reporting with The Council of State and Territorial Epidemiologists (CSTE) and The Association of Public Health Laboratories (APHL). https://ecr.aimsplatform.org/about-us#:~:text=A%20US%20federal%20agency%20under,the%20United%20States%20and%20internationally.

National Health Care Survey Registry - HL7 CDA® R2 Implementation Guide: National Health Care Surveys (NHCS), R1 STU Release 1.2 was never named in a final rule but rather became part of Promoting Interoperability through Certification Companion Guide (CCG) and Test Procedures Updates to the ISA in 2017. https://www.cdc.gov/nchs/dhcs/nhcs_registry_home_page.htm

EPIC stork module (obstetrics) for birth reporting. https://www.epic.com/software#PatientEngagement

IHE integration profiles for BFDR (CDA). https://www.ihe.net/uploadedFiles/Documents/QRPH/IHE_QRPH_Suppl_BFDR-E.pdf

EPIC FHIR patient, vitals, obstetric details (DSTU2, DSTU3, R4): https://fhir.epic.com/Specifications?api=932, https://fhir.epic.com/Specifications?api=968, https://fhir.epic.com/Specifications?api=966

Cerner FHIR patient resource (DSTU2, R4): http://fhir.cerner.com/millennium/r4/individuals/patient/#retrieve-by-id

Evident FHIR patient resource (DSTU2): https://api.evident.com/dstu2/patient

Allscripts FHIR patient resource (DSTU2): https://developer.allscripts.com/FHIR?PageTitle=Resources

Promoting Interoperability Programs Eligible Hospitals and Critical Access Hospitals are required to, and Merit-based Incentive Payment System (MIPS) participants may optionally, report on any two measures under the Public Health and Clinical Data Exchange objective of these programs. The § 170.315(f)(5) – Transmission to public health agencies – electronic case reporting certification criteria in the 2015 Edition Final Rule and the ONC Cures Act Final Rule, the § 170.315(f)(7) – Transmission to public health agencies – health care surveys, and the § 170.315 (f)(4) – Transmission to Cancer Registries are three such options to meet these measures.

The current standard for § 170.315(f)(5), as listed in ONC’s 2020 Interoperability Standards Advisory Reference Edition, is HL7® CDA® R2 Implementation Guide: Public Health Case Report, Release 2: the Electronic Initial Case Report (eICR), Release 1, STU Release 1.1. ONC’s Certified Health IT Product List (CHPL) lists 73 EHR or HIT Module products certified to (f)(5) using this standard. eCR IG: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=436

The current standard for § 170.315(f)(7), as listed in ONC’s 2020 Interoperability Standards Advisory Reference Edition, is HL7® CDA® R2 Implementation Guide: National Health Care Surveys (NHCS), R1 DSTU Release 1.2 - US Realm. ONC’s Certified Health IT Product List (CHPL) lists 116 EHR or HIT Module products certified to (f)(5) using this standard. NHCS IG: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=385

The current standard for § 170.315 (f)(4), as listed in ONC’s 2020 Interoperability Standards Advisory Reference Edition, is HL7 CDA® R2 IG: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, R1, DSTU Release 1.1 - US Realm. ONC’s Certified Health IT Product List (CHPL) lists 288 EHR or HIT Module products certified to (f)(4) using this standard. Cancer Reporting IG: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=398

These three widely adopted CDA standards have many of the Patient Demographic data elements contained on this form as Shall (required) or Should (best practice to include if available) conformance criteria, which demonstrates the maturity of these commonly exchanged data elements.

Supporting Links:
eCase Reporting: https://ecr.aimsplatform.org/about-us#:~:text=A%20US%20federal%20agency%20under,the%20United%20States%20and%20internationally.

NHCS: https://www.cdc.gov/nchs/dhcs/nhcs_registry_home_page.htm

EPIC stork module (obstetrics) for birth reporting: https://www.epic.com/software#PatientEngagement

IHE integration profiles for BFDR (CDA): https://www.ihe.net/uploadedFiles/Documents/QRPH/IHE_QRPH_Suppl_BFDR-E.pdf

EPIC FHIR patient, vitals, obstetric details: https://fhir.epic.com/Specifications?api=932, https://fhir.epic.com/Specifications?api=968, https://fhir.epic.com/Specifications?api=966

Cerner FHIR patient resource: http://fhir.cerner.com/millennium/r4/individuals/patient/#retrieve-by-id

Evident FHIR patient resource: https://api.evident.com/dstu2/patient

Allscripts FHIR patient resource: https://developer.allscripts.com/FHIR?PageTitle=Resources

eCR IG: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=436

NHCS IG: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=385

Cancer Reporting IG: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=398
https://ecr.aimsplatform.org/about-us#:~:text=A%20US%20federal%20agency%20under,the%20United%20States%20and%20internationally. https://www.cdc.gov/nchs/dhcs/nhcs_registry_home_page.htm
Extent of exchange 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 Level 2 – exchanged between 4 or more different EHR/HIT systems. More routinely exchanged between multiple different systems can justify adding to the next draft version.

At least 38 state cancer registries have received cancer reports from at least one provider (per internal technical and programmatic documentation) that include these data elements: Patient Medical Record Number, Patient Social Security Number, Patient Marital Status, Patient Address Use Period.

HL7 CDA® R2 Implementation Guide: Public Health Case Report, Release 2 - US Realm - the Electronic Initial Case Report (eICR) is currently implemented in 5,400+ reporting sites nationally and exchanges the following Patient Demographic elements: Patient Identifiers, Patient Marital Status, Patient Gender Identity, Patient Pregnancy Status Observation. HL7 CDA® R2 Implementation Guide: Public Health Case Report, Release 2 - US Realm - the Electronic Initial Case Report (eICR): https://www.hl7.org/implement/standards/product_brief.cfm?product_id=436

IHE Connectathon integration profiles for BFDR (2013 - 2020) and Cancer reporting (2010 - 2020), death reporting (2019) - tested between electronic death registration vendors (EDRS) and NCHS. IHE: Found in 'New Search', filter by 'Select an integration profile' https://connectathon-results.ihe.net/view_result.php?rows=company&columns=actor&title=integration_profile. IHE Connectathon: https://connectathon-results.ihe.net/view_result.php?rows=company&columns=actor&title=integration_profile

HL7 FHIR Connectathon results (Sept 2020): MedMorph/eCR, birth and fetal death reporting, Integrating cancer reporting. https://confluence.hl7.org/display/FHIR/2020-09+Public+Health+Track

NACCHO 360X Interoperability Demonstrations for Cancer, eCR, Birth and Fetal Death and Death reporting 2020 (CDA and FHIR)
https://www.hl7.org/implement/standards/product_brief.cfm?product_id=436
Potential Challenges
Restrictions on Standardization (e.g. proprietary code) None
Restrictions on Use (e.g. licensing, user fees) None
Privacy and Security Concerns Concerns with the use of personally identifying information (PII). However, these data are intended to be a part of the medical record and will be protected as such using proper secure protocols.
Estimate of Overall Burden For those use cases not currently in production level or who have not tested with vendors may require additional development hours or resources.
Other Implementation Challenges When using FHIR there may be associated costs with the development of tools needed to access specific data. Often these costs may be a limitation for states who need to develop tools to access certain data.
ASTP 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 2 - Data element is 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 1 - Use cases apply to several care settings or specialties.
Evaluation Comment Assessed to remain at Level 1 due to security and privacy concerns related to SSN capture, exchange, and use.

Comment

Submitted by nedragarrett_CDC on

CDC comments on Patient's Social Security Number

CDC requests the inclusion of Patient's Social Security Number (SSN) as a USCDIv6 data element 

Justification: The process of completing and submitting a death certificate to a vital records office involves both a funeral director as well as a medical certifier. Each of these two entities provide data needed for completion of the death certificate.  While the decedent’s SSN is typically provided by the funeral director, there are instances in which the information is only available from the medical certifier and hence would be beneficial to have as a core data element within the EHR being used by the medical certifier. In additional to death reporting the US Standard Certificate of Live Birth has an element for the SSN of both the mother and the father. The source of this information is provided directly from the mother and/or father. In the development of patient portals, input of these elements would allow for direct transfer from EHRs to vital records systems. Ongoing CDC modernization initiatives are working towards interoperability with EHRs, and data collection system used by the vital records office, known as an electronic death registration system (EDRS) and electronic birth registration systems, and in this scenario, SSN could be used for record matching, making it an important core data element provided by the EHR for both death and birth certification.  

Sources: U.S. STANDARD CERTIFICATE OF DEATH -- REV. 11/2003 (cdc.gov); NVSS - Modernization - Projects and Initiatives (cdc.gov); U. S. Standard Certificate of Live Birth (November 2003) (cdc.gov) 

Submitted by nedragarrett_CDC on

Unified Comment from CDC

  • NOTE - This comment supports the promotion of the Data Class Patient Demographics - Data Element Identifier to USCDI V3 as well as the additional Data Element of Identifier System, including the allowance of multiple instances of Identifier/ Identifier System per patient. We believe that this will allow needed flexibility to accommodate use and exchange of the variety of patient identifiers in current use in the US. An example of this approach is: Identifier: 333224444, Identifier System: http://hl7.org/fhir/sid/us-ssn. If ONC does not choose to incorporate this approach (Identifier + Identifier System) in USCDI V3, we recommend allowing for the following Patient Demographic Data Class Data Elements in USCDI V3: Medicare Patient Identifier, Medical Record Number and Social Security Number.
     
  • Data element description: The Social Security Number is a 9-digit number issued to almost all U.S. citizens and eligible U.S. residents. It is used to track Social Security benefits and for other identification purposes.
     
  • General Comment: The Social Security Number is used as a patient identifier by many Health Care Organizations and their EHRs and other HIT systems. It is also a required field in death certificates in the US. Social Security Number has a system element of the FHIR Identifier data type of: http://hl7.org/fhir/sid/us-ssn . The reviewers of this comment should be aware of the following HL7 US Core Patient Profile “Profile specific implementation guidance” notation: “The Patient’s Social Security Numbers SHOULD NOT be used as a patient identifier in Patient.identifier.value. There is increasing concern over the use of Social Security Numbers in healthcare due to the risk of identity theft and related issues. Many payers and providers have actively purged them from their systems and filter them out of incoming data.” (http://hl7.org/fhir/us/core/structuredefinition-us-core-patient.html ) Although this comment agrees that some health care organizations are beginning to decrease or eliminate their use of Social Security Number use for patient identification, we believe that this HL7 guidance is not nearly representative of the current status of patient identifiers in the US. Social Security Number continues to be one of, and in some case the primary, identifier of patients for health systems in the United States. Given appropriate safeguarding of this as well as any other form of protected health information, continued use of Social Security Number likely to occur for the foreseeable future in the healthcare ecosystem. Indeed, given Social Security Number’s use in social service agencies, its use as an important identifier for Social Determinants of Health purposes is likely to grow. Social Security Number is used in the MedMorph Health Care Surveys, Cancer Registry Reporting and Birth Defects Public Health use cases to link records within each registry. For Health Care Surveys and Cancer Registry Reporting, it is further used to link to the National Death Index and several CMS datasets. For these reasons this commentor strongly supports promotion of Social Security Number to inclusion in USCDI V3. Should ONC not find enough support to promote Social Security Number to inclusion in USCDI V3, promotion to USCDI Level 2 is another option, allowing acknowledgement that this is a widely used and exchanged data element yet allowing more and diverse input in the debate of its ultimate advisability for inclusion in a USCDI version.

Submitted by maria.michaels… on

Specific Identifier(s) or general Identifier?

MedMorph supports the addition of Patient Social Security Number (Level 1), but is concerned with having a general Identifier element (level 2) as well as Medical Record Number (Level 1) and Medicare Patient Identifier (Level 2). What is the intention of Identifier - is it a placeholder for a national identifier of some sort for a patient? We recommend that USCDI either take a general approach with Identifier Type, Identifier System, and Identifier Value OR be specific with Medical Record Number, Medicare Patient Identifier and Social Security Number elements (and remove the Identifier element).

Log in or register to post comments