{"text_format":"3","workbook":"xlsx","n_sheets":14,"sheets":["ReadMe","Clinical Notes","Current Pregnancy","Encounter","Immunizations","Laboratory","Medications","Mother's Delivery Info","Newborn's Delivery Info","Patient Demographics","Patient Work","Problems","Procedures","Sheet2"],"not_rendered":{"macros":1,"comments":16},"read":"whole","date_system":"1900"}

{"sheet":"ReadMe","index":0,"n_rows":12,"n_cols":1,"rows_kept":12}
["OVERVIEW/ INSTRUCTIONS"]
[]
["Each tab of the file represents a current or proposed new USCDI Data Class. "]
["The rows on each tab indicate elements we are proposing to be added to USCDI. "]
["The columns are fields from the ONDEC Submission Prep Form."]
[]
["Please review and provide comments using the excel comment feature. "]
["Please highlight (choose whatever color you wish) each cell that you provide a comment for. —"]
["Please be concise on your feedback; provide specific verbiage changes. Please refrain from using the phrase “suggest rewording” – please provide the specific wording."]
[]
["When finished reviewing, please save the file as MedMorph_ONDEC_Consolidated_Data_Classes_[your last name or organization].xls. "]
["—Email the file to becky.angeles@carradora.com by COB on Monday, October 5th."]

{"sheet":"Clinical Notes","index":1,"n_rows":3,"n_cols":33,"rows_kept":3,"merged":[[1,6,2,6],[1,7,2,7],[1,8,2,8],[1,9,2,9],[1,10,2,10],[1,11,2,11],[1,12,2,12],[1,13,2,13],[1,14,2,14],[1,15,2,15],[1,16,2,16],[1,17,2,17],[1,18,2,18],[1,19,2,19],[1,20,2,20],[1,21,2,21],[1,22,2,22],[1,23,2,23],[1,24,2,24],[1,25,2,25],[1,26,2,26],[1,27,2,27],[1,28,2,28],[1,29,2,29],[1,30,2,30],[1,31,2,31],[1,32,2,32]]}
[null,"DATA CLASS       Data Class Name","DATA ELEMENT  (1…m Data Element(s) per Data Class)                         Data Element Name","Data Element Description","Similar or related D E's in USCDI","If Yes, why DE considered separately?","USE CASE                                                                                                                               Describe the main use cases to support adoption of the DE into USCDI","Estimate # of stakeholders who would capture, access, use or exchange this DE or DC*","Link to use case project page","Please describe the additional use case:*","FOR ADD USE CASE - Estimate # of stakeholders who would capture, access, use or exchange this DE or DC*","FOR ADD USE CASE -Link URL ","Attachment describing this (unclear if main or ADD Use Case(s)) use case","Does this data element support the following aims in healthcare?* (Check all that Apply)","MATURITY                                    Does a vocabulary, terminology, content, or structural standard exist for this data element? (e.g., SNOMED CT, LOINC, RxNorm) * (select one)","If yes, please cite the applicable standard*","If yes, link URL","Are there additional technical specifications such as an implementation guide (IG) or profile using this data element? (e.g., HL7® FHIR® US Core Implementation Guide v3.1.0 based on FHIR R4)  ","If yes, please cite the relevant technical specification(s)*","Which of the following best describes the use of this data element?* (select one)","Please cite supporting artifacts*","Link URL","Attachment","Has this data element been electronically exchanged with external organizations or individuals (including patients)?* (select one)","If yes, with how many outside entities has this been exchanged?* ","Please cite supporting artifacts:*","Supporting Link","Attachment","CHALLENGES                                      Describe any restrictions on the standardization of this data element \n(e.g., proprietary code).*","Describe any restrictions on the use of this data element (e.g., licensing, user fees).*","Describe any privacy and security concerns with the use and exchange of this data element.*","Please provide an estimate of overall burden to implement. Overall estimate of burden to implement, including those not affected by the primary use case(s) (i.e., impact to broader healthcare community for specialty-specific data element submission.)*","Please provide information on other challenges to implementation"]
[null,"Clinical notes","Death note?","Causes of death are diseases, abnormalities, injuries, or\npoisonings that contributed directly or indirectly to death.\n\nCause of death can be captured across multiple data classes and elements: Clinical notes, problems, procedures, health concerns, medications, labs, vital signs.  What items are missing from USCDI that we should include to help inform the cause of death for providers? Death note summary?  LOINC codes has been identified. ",null,null,"Monitoring disease and making decisions about public health threats depends on accessible and accurate data. EHRs are a data source with 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.\n\nFor deaths that occur in a hospital cause of death information can be found within various sections of a patient's electronic health record.  There are current USCDI data classes and elements that capture items that would help inform cause of death for a patient.  However, it is important to capture the whole picture of information when determining cause of death. Sections or modules from an EHR  will help inform the certifying physician when interoperability is gainfully supported between an EHR and a state's electronic death registration system (EDRS).  Additionally, there are other public health use cases that would be supported when it comes to cause of death associated with disease reporting requirements. Those public health use cases include Hepatitis C and Patient Center-Clinical Research Network (PCORnet). \n\nThe 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. 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. ","Each year there are appropriately 2.8 million deaths in the United States. Deaths are certified by the attending physician or the Medical Examiner/Coroner in the Electronic Death Registration System.  The cause of death information would be useful for the proportion of deaths that occur in a hospital or health care setting and/or for which an EHR record is available. The percent of deaths in the US for which a EHR records exists is largely unknown but given the large volume of deaths in the US each year, even a small percentage can result in substantial gains in overall efficiency. ","https://www.cdc.gov/csels/phio/making-ehr-data-more-available.html\n\nhttps://www.cdc.gov/nchs/nvss/deaths.htm\n\nhttps://www.cdc.gov/hepatitis/hcv/index.htm\n\nhttps://pcornet.org/\n\n\n\n",{"$nulls":4},"More than 1 but not all","Yes","LOINC:\n47046-8 Summary of death note\n83796-3 Physician Summary of death note\n84273-2 Nurse Summary of death note\n\nUS Standard Certificate of Death\n\n","https://loinc.org/47046-8/\nhttps://loinc.org/83796-3/\nhttps://loinc.org/84273-2/\n\nhttps://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.114222.4.11.3593\n\nhttps://www.cdc.gov/nchs/data/dvs/DEATH11-03final-ACC.pdf","Yes"," IHE Quality, Research and Public Health Technical Framework Supplement – Vital Records\nVital Records Death Reporting FHIR Implementation Guide 1.0\n\n","In limited use in test environments only","IHE Connectathon integration profiles for death reporting (2019) - tested between electronic death registration vendors (EDRS) and NCHS. \n\nHL7 FHIR Connectathon results (Sept 2019 and 2020): Death reporting - tested between EDRS to EDRS (2019) and EDRS to NCHS (2019, 2020). ","Found in 'New Search', filter by 'Select an integration profile = Vital Records Death Reporting'\nhttps://connectathon-results.ihe.net/view_result.php?rows=company&columns=actor&title=integration_profile\n\nhttps://confluence.hl7.org/display/FHIR/2020-09+Public+Health+Track\n",null,"Yes","5 or more","Multiple public health agencies  are recipients of a death certificate to include NAPHSIS, other jurisdictions, surveillance programs such as cancer and NCHS: \n\nIHE Connectathon integration profiles for death reporting (2019) - tested between (4) electronic death registration vendors (EDRS) and NCHS. \n\nHL7 FHIR Connectathon results (Sept 2019 and 2020): tested between (5 -7) electronic death registration vendors (EDRS) and NCHS. \n\nNACCHO 360X Interoperability Demonstrations for Death reporting 2020 (FHIR) tested between EDRS and NCHS","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\n\nhttps://confluence.hl7.org/display/FHIR/2020-09+Public+Health+Track\n",null,"None ","None","None","If this data is already in the EHR, then the burden to implement should be minimal because it does not require the creation of a new data element or modifying an existing one. ","When using FHIR there may be associated costs with 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.  "]
[null,"Clinical notes","Date and Time Pronounced Dead","Month, day and year decedent was pronounced dead. Hour and minute decedent was pronounced dead.  Spell out the name of the month.  Enter the exact hour and minutes according to a 24-hour clock; estimates may be provided with “Approx.” placed before the time. \n"]

{"sheet":"Current Pregnancy","index":2,"n_rows":4,"n_cols":33,"rows_kept":4,"merged":[[1,6,3,6],[1,7,3,7],[1,8,3,8],[1,9,3,9],[1,10,3,10],[1,11,3,11],[1,12,3,12],[1,13,3,13],[1,14,3,14],[1,15,3,15],[1,16,3,16],[1,17,3,17],[1,18,3,18],[1,19,3,19],[1,20,3,20],[1,21,3,21],[1,22,3,22],[1,23,3,23],[1,24,3,24],[1,25,3,25],[1,26,3,26],[1,27,3,27],[1,28,3,28],[1,29,3,29],[1,30,3,30],[1,31,3,31],[1,32,3,32]]}
[null,"DATA CLASS       Data Class Name","DATA ELEMENT  (1…m Data Element(s) per Data Class)                         Data Element Name","Data Element Description","Similar or related D E's in USCDI","If Yes, why DE considered separately?","USE CASE                                                                                                                               Describe the main use cases to support adoption of the DE into USCDI","Estimate # of stakeholders who would capture, access, use or exchange this DE or DC*","Link to use case project page","Please describe the additional use case:*","FOR ADD USE CASE - Estimate # of stakeholders who would capture, access, use or exchange this DE or DC*","FOR ADD USE CASE -Link URL ","Attachment describing this (unclear if main or ADD Use Case(s)) use case","Does this data element support the following aims in healthcare?* (Check all that Apply)","MATURITY                                    Does a vocabulary, terminology, content, or structural standard exist for this data element? (e.g., SNOMED CT, LOINC, RxNorm) * (select one)","If yes, please cite the applicable standard*","If yes, link URL","Are there additional technical specifications such as an implementation guide (IG) or profile using this data element? (e.g., HL7® FHIR® US Core Implementation Guide v3.1.0 based on FHIR R4)  ","If yes, please cite the relevant technical specification(s)*","Which of the following best describes the use of this data element?* (select one)","Please cite supporting artifacts*","Link URL","Attachment","Has this data element been electronically exchanged with external organizations or individuals (including patients)?* (select one)","If yes, with how many outside entities has this been exchanged?* ","Please cite supporting artifacts:*","Supporting Link","Attachment","CHALLENGES                                      Describe any restrictions on the standardization of this data element \n(e.g., proprietary code).*","Describe any restrictions on the use of this data element (e.g., licensing, user fees).*","Describe any privacy and security concerns with the use and exchange of this data element.*","Please provide an estimate of overall burden to implement. Overall estimate of burden to implement, including those not affected by the primary use case(s) (i.e., impact to broader healthcare community for specialty-specific data element submission.)*","Please provide information on other challenges to implementation"]
[null,"Current Pregnancy","Last Menstrual Period","The last menstrual period of the patient. If known, the first day of last menstrual period should be captured.","No",null,"Monitoring disease and making decisions about public health threats depends on accessible and accurate data. EHRs are a data source with 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.       \n\nAn expectant mother’s pregnancy attributes are crucial for providing the best possible pre-natal care. As well, after delivery, public health needs to capture this data as part of birth certification, fetal death reporting and birth defect reporting. Birth certification forms the basis of the patient census required by many other public health programs including newborn screening, birth defect reporting and immunization registries making it critical that birth certification is as automated, timely and accurate as possible.\n\nThe 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. 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. ","Every year there are approximately 3.7 million births in the United States. Consumption of this data is widespread. Every jurisdiction in the country captures birth certification information and immunization administration. Most also capture birth defects and fetal deaths. Healthcare systems which provide care for expectant mothers should be collecting this data.","https://www.cdc.gov/csels/phio/making-ehr-data-more-available.html\nhttps://www.cdc.gov/nchs/nvss/births.htm\nhttps://www.cdc.gov/ncbddd/birthdefects/index.html",{"$nulls":4},"More than 1 but not all","Yes","LOINC codes exist for each of the proposed data elements:\n8665-2 - Last menstrual period start date\n11778-8 - Delivery date Estimated\n56077-1 - Body weight --pre current pregnancy","https://loinc.org/","Yes","Vital Records Common Profiles Library FHIR IG - http://build.fhir.org/ig/HL7/fhir-vr-common-ig/branches/master/index.html\nVital Records Birth and Fetal Death Reporting - https://build.fhir.org/ig/HL7/fhir-bfdr/index.html\nHL7 Version 2.6 Implementation Guide: Vital Records Birth and Fetal Death Reporting, Release 1 STU Release 2 - US Realm https://www.hl7.org/implement/standards/product_brief.cfm?product_id=320\n\nHL7 CDA® R2 Implementation Guide: Birth and Fetal Death Reporting, Release 1, STU Release 2 - US Realm -https://www.hl7.org/implement/standards/product_brief.cfm?product_id=387\n\nIHE Quality, Research and Public Health Technical Framework Supplement – Birth and Fetal Death Reporting-Enhanced (BFDR-E) Revision 3.1 - https://www.ihe.net/uploadedFiles/Documents/QRPH/IHE_QRPH_Suppl_BFDR-E.pdf\n\nBirth Defect Reporting FHIR IG - https://build.fhir.org/ig/HL7/fhir-birthdefectsreporting-ig/index.html\n\nHL7 CDA® R2 Implementation Guide: Ambulatory and Hospital Healthcare Provider Reporting to Birth Defect Registries Release 1 , STU 2 -US Realm - https://www.hl7.org/implement/standards/product_brief.cfm?product_id=428\n","In limited use in production environments","This data is exchanged routinely as part of birth certification, fetal death reporting and birth defect reporting, however these workflows typically are executed on paper or via flat files rather than through electronic interoperability.\nEPIC FHIR APIs for patient, vitals, obstetric details (DSTU2, DSTU3, R4)\nIn production use:\nEPIC stork module (obstetrics) for birth reporting","Facility worksheet information:\nhttps://www.cdc.gov/nchs/data/dvs/facility-worksheet-2016-508.pdf\nhttps://www.cdc.gov/nchs/data/dvs/fetal-death-mother-worksheet-english-2019-508.pdf\nEPIC stork module (obstetrics) for birth reporting: https://www.epic.com/software#PatientEngagement\nEPIC FHIR APIs for patient, vitals, obstetric details:\nhttps://fhir.epic.com/Specifications?api=932\nhttps://fhir.epic.com/Specifications?api=968\nhttps://fhir.epic.com/Specifications?api=966\n",null,"Yes","5 or more","IHE Connectathon integration profiles for BFDR-E (2013 - 2020)\n\nHL7 FHIR Connectathon results (Sept 2020): birth and fetal death reporting results testing between electronic birth registration system vendors (FHIR)\n\nNACCHO 360X Interoperability Demonstrations for Birth and Fetal Death reporting 2020 between NextGen and two state electronic birth registrations system vendors using FHIR.\n\nHIMSS Interoperability showcase (2018 – 2019)","Found in 'New Search', filter by 'Select an integration profile = Birth and Fetal Death Reporting-Enhanced'  https://connectathon-results.ihe.net/view_result.php?rows=company&columns=actor&title=integration_profile\n\nhttps://confluence.hl7.org/display/FHIR/2020-09+Public+Health+Track\nhttps://www.interoperabilityshowcase.org/",null,"None ","None","No concerns over and above the typically privacy and security considerations associated with any health related data.","These data elements are straightforward in nature and should not present a large burden to implement provided the EHR system is capturing the data as part of caring for the woman.","When using FHIR there may be associated costs with 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.  "]
[null,"Current Pregnancy","Estimated Date of Delivery","The expected date of delivery (i.e. the due date)."]
[null,"Current Pregnancy","Mother’s Prepregnancy Weight","The weight of the mother before becoming pregnant."]

{"sheet":"Encounter","index":3,"n_rows":23,"n_cols":33,"rows_kept":23,"merged":[[1,6,22,6],[1,7,22,7],[1,8,22,8],[1,9,22,9],[1,10,22,10],[1,11,22,11],[1,12,22,12],[1,13,22,13],[1,14,22,14],[1,15,22,15],[1,16,22,16],[1,17,22,17],[1,18,22,18],[1,19,22,19],[1,20,22,20],[1,21,22,21],[1,22,22,22],[1,23,22,23],[1,24,22,24],[1,25,22,25],[1,26,22,26],[1,27,22,27],[1,28,22,28],[1,29,22,29],[1,30,22,30],[1,31,22,31],[1,32,22,32]]}
[null,"DATA CLASS       Data Class Name","DATA ELEMENT  (1…m Data Element(s) per Data Class)                         \nData Element Name","Data Element Description","Similar or related D E's in USCDI","Why D E considered separately?","USE CASE                                                                                                                               Describe the main use cases to support adoption of the DE into USCDI","Estimate # of stakeholders who would capture, access, use or exchange this DE or DC","Link to use case project page","Please describe the additional use case:*","FOR ADD USE CASE - Estimate # of stakeholders who would capture, access, use or exchange this DE or DC","FOR ADD USE CASE -Link URL ","Attachment describing this (unclear if main or ADD Use Case(s)) use case","Does this data element support the following aims in healthcare?","MATURITY                                    Does a vocabulary, terminology, content, or structural standard exist for this data element? (e.g., SNOMED CT, LOINC, RxNorm) * (select one)","If yes, please cite the applicable standard","If yes, link URL","Are there additional technical specifications such as an implementation guide (IG) or profile using this data element? (e.g., HL7® FHIR® US Core Implementation Guide v3.1.0 based on FHIR R4)  ","If yes, please cite the relevant technical specification(s)*","Which of the following best describes the use of this data element?* (select one)","Please cite supporting artifacts","Link URL","Attachment","Has this data element been electronically exchanged with external organizations or individuals (including patients)?* (select one)","If yes, with how many outside entities has this been exchanged?* ","Please cite supporting artifacts:*","Supporting Link","Attachment","CHALLENGES                                      Describe any restrictions on the standardization of this data element \n(e.g., proprietary code).*","Describe any restrictions on the use of this data element (e.g., licensing, user fees).*","Describe any privacy and security concerns with the use and exchange of this data element.*","Please provide an estimate of overall burden to implement. Overall estimate of burden to implement, including those not affected by the primary use case(s) (i.e., impact to broader healthcare community for specialty-specific data element submission.)*","Please provide information on other challenges to implementation"]
[null,"Encounter","Encounter status","\tCurrent state of the encounter.","No","N/A","Actively monitoring diseases, making decisions about public health threats, identifying trends in healthcare services utilization and other public health matters depend on accessible and accurate patient data. EHRs are a data source that can 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 more rapid disease detection, tracking, and treatment and innovation in healthcare delivery. \n\nA patient's encounter with a provider of medical services, ranging from an ambulatory office visit with the patient's primary care provider, to a sudden, acute injury necessitating a trip to an Emergency Department to an admission to and subsequent discharge from a hospital for surgery is a fundamental organizing principal across the healthcare industry. The encounter class of data elements are widely used in EHRs and other systems for clinical care, payment purposes and operational efficiency.  Beginning with the encounter status, often used as a trigger for clinical workflow, through classifying, numerically identifying and assigning a data and time to the encounter, to identifying the patient and provider subjects of the encounter as well as their roles form the structure of the encounter these encunter element have varied clinical and administrative uses.  The chief compliant, reason for visit and encounter diagnoses capture the richness of the encounter while the expected source of encounter payment and encounter discharge disposition provide information for follow up and payment. The  majority of the candidate encounter data elements here are either mandatory or must support data elements of the US CORE Encounter Profile or Shall or Should data elements in many CDA use cases.\n\nThe Making EHR Data More Available for Research and Public Health (MedMorph) project's goal is to create a reliable, scalable, and interoperable method to get electronic health record data for multiple public health and research scenarios (use cases). MedMorph has identified Cancer Registry Reporting, Healthcare Surveys, Electronic Initial Case Reporting (eCR), Hepatitis C Reporting, and Research (PCORNet) use cases that support the adoption of  these encounter data elements. These specific use cases are described in more depth on their respective web pages. ","All 50 states participate in one or more of the MedMorph public health and research use cases that exchange these encounter data elements. Up to 14 territorial or city jurisdictions also participate in one of these public health use cases and use these data elements. \n\nAll hospitals and physicians who diagnose or treat cancer are required to provide encounter information to state cancer registries. \n\nApproximately 600,000 physicians in the US are active and have at least some component of ambulatory practice and thus are annually eligible for sampling and recruitment into the National Ambulatory Medical Care Survey (NAMCS), one of the two Health Care Surveys in the MedMorph Health Care Surveys Use Case.  NAMCS, 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. The second Health Care Survey addressed in the MedMorph Health Care Surveys Use case is the National Hospital Care Survey (NHCS).  Approximately 600 hospitals are in  the NHCS sample.  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, containing most of the  encounter data elements in this submission, and will require all of these  encounter data element in the HL7 FHIR Health Care Surveys content planned to be balloted in 2021. When NHCS reaches their target of 200 hospitals submitting by this mode annually they will be receiving >1.2 million documents, which all include encounter data,  annually.                                            \nThere 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 many of the admissions interact with one or more of the public health and or research use cases. The vast majority of these exchanges include most or at least some of the encounter data elements contained in this submission.","https://www.cdc.gov/csels/phio/making-ehr-data-more-available.html\n\nhttps://www.cdc.gov/cancer/npcr/\n\nhttps://www.cdc.gov/hepatitis/pdfs/HepatitisCaseRprtForm.pdf\n\nhttps://www.cdc.gov/nchs/dhcs/nhcs_registry_landing.htm\n\nhttps://www.cdc.gov/ecr/index.html\n\nhttps://pcornet.org/","A foundational goal of MedMorph is generalizability beyond the 10 use cases that are actively informing the MedMorph project, in order 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 these encounter data elements. ",{"$nulls":3},"Improving the health of populations ","Yes","Encounter Status: FHIR Encounter Status \n\nClassification of Encounter: V3 Value SetActEncounterCode \n\nEncounter Type: FHIR Encounter type\n\nEncounter participant type: FHIR Participant type\n\nReason for the visit: FHIR Encounter Reason Codes\n\nHospital encounter discharge disposition: FHIR Discharge disposition \n\nExpected source(s) of payment for this encounter: FHIR Coverage Type and Self-Pay Codes \n\nEncounter chief complaint: FHIR DiagnosisRole","Encounter Status: http://hl7.org/fhir/ValueSet/encounter-status\n\nClassification of Encounter:http://hl7.org/fhir/ValueSet/v3-ActEncounterCode\n\nEncounter Type: http://www.ama-assn.org/go/cpt\n\nEncounter participant type: \nhttp://hl7.org/fhir/ValueSet/encounter-participant-type\n\nReason for the visit: http://hl7.org/fhir/ValueSet/encounter-reason\n\nHospital encounter discharge disposition: http://hl7.org/fhir/ValueSet/encounter-discharge-disposition\n\nhttp://hl7.org/fhir/R4/valueset-coverage-type.html\n\nhttp://hl7.org/fhir/R4/valueset-diagnosis-role.html\n\n\n","Yes","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)\n\nHL7 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)\n\nC-CDA (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) \n\nHL7 FHIR® US Core Implementation Guide STU3 Release 3.1.1 (https://www.hl7.org/fhir/us/core/index.html)                                                                                                                                                                                                                                                                                                                                                         Resource Encounter - Content  - (https://www.hl7.org/fhir/encounter.html)\n\nHL7 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)\n\nHL7 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)","Extensively used in production environments","Widely available in EHR systems.\n\nPart of EHR Certification for Transmission to Cancer Registries (2015 and 2014 Editions)\n\nThese data elements exist in FHIR with a FHIR Maturity level of 2 for the Encounter Resource data elements\n\nIHE Connectathons 2010-2020 (CDA; as part of Cancer Reporting IGs)\nHIMSS Interoperability Showcase 2010-19 (CDA; as part of Cancer Reporting IGs)\nPublic Health Informatics Conference Interoperability Showcase 2014, 2016, 2018 (CDA; as part of Cancer Reporting IGs)\nNACCHO 360X Interoperability Demonstrations, 2020 (CDA; as part of Cancer Reporting IGs)\n\nIHE Connectathons 2019-2020 (CDA; as part of National Health Care Surveys IGs)                                     ","https://www.hl7.org/fhir/encounter.html",null,"Yes","5 or more. This data element has been tested at scale between multiple different production environments to support the majority of anticipated stakeholders. ","IHE Connectathons 2010-2020 (CDA; as part of Cancer Reporting IGs)\nHIMSS Interoperability Showcase 2010-19 (CDA; as part of Cancer Reporting IGs)\nPublic Health Informatics Conference Interoperability Showcase 2014, 2016, 2018 (CDA; as part of Cancer Reporting IGs)\nNACCHO 360X Interoperability Demonstrations, 2020 (CDA; as part of Cancer Reporting IGs)\n\nIHE Connectathons 2019-2020 (CDA; as part of National Health Care Surveys IGs)                                                                                     ONC Interoperability Standards Advisory - Sending Health Care Survey Information to Public Health Agencies - see:                                      https://www.healthit.gov/isa/sending-health-care-survey-information-public-health-agencies       ","https://chpl.healthit.gov/#/search: 170.315 (f)(4): Transmission to Cancer Registries\nRetired | 170.314 (f)(5): Optional - ambulatory setting only - cancer case information\nRetired | 170.314 (f)(6): Optional - ambulatory setting only - transmission to cancer registries)",null,"None.","None.","None.","Low.\n\nEHRs use encounters as fundamental organizing structure so this set of encounter data elements are already \"baked in\" to EHRs used by providers. Providers and EHR products will experience no burden for something they already use widely other than EHR companies extending the availability of these data elements to USCDI data sets.  Several existing IGs, as listed, require exchange of this data element. The Promoting Interoperability Programs Objective 8 - Public Health and Clinical Data Registry Reporting, measures 3 -: Electronic Case Reporting and 4: Public Health Registry Reporting require these data elements.\n \nEncounter information is routinely communicated in HL7 CDA Documents and some FHIR API transactions.","None."]
[null,"Encounter","Classification of Encounter","Concepts representing classification of patient encounter such as ambulatory (outpatient), inpatient, emergency, home health or others due to local variations.","No","N/A"]
[null,"Encounter","Encounter type","Specific type of encounter (e.g. e-mail consultation, surgical day-care, skilled nursing, rehabilitation).","No","N/A"]
[null,"Encounter","Encounter subject","The patient or group present at the encounter.","No","N/A"]
[null,"Encounter","Encounter Identifier","Identifier(s) by which this encounter is known.","No","N/A"]
[null,"Encounter","Encounter period","The start and end times of the encounter.","No","N/A"]
[null,"Encounter","Encounter participant type","Role of participant in encounter.","No","N/A"]
[null,"Encounter","Participant overseeing the encounter","Participant overseeing the encounter.","No","N/A"]
[null,"Encounter","Primary participant responsible for encounter ","Encounter primary performer of service.","No","N/A"]
[null,"Encounter","Encounter participant individual","Persons involved in the encounter other than the patient. Reference(US Core Practitioner Profile)","No","N/A"]
[null,"Encounter","Encounter primary performer NPI","NPI of encounter primary performer.","No","N/A"]
[null,"Encounter","Encounter primary performer name","Name of encounter primary performer.","No","N/A"]
[null,"Encounter","Encounter primary performer professional  role","Professional role of encounter primary performer.","No","N/A"]
[null,"Encounter","Time period participant participated in the encounter","The period of time that the specified participant participated in the encounter. These can overlap or be sub-sets of the overall encounter's period.","No","N/A"]
[null,"Encounter","Reason for the visit","Reason the encounter takes place, expressed as a code.","No","N/A"]
[null,"Encounter","Diagnoses relevant to this encounter","The list of diagnosis relevant to this encounter.","No","N/A"]
[null,"Encounter","Encounter primary diagnosis","Reason the encounter takes place, as specified using information from another resource. For admissions, this is the admission diagnosis. The indication will typically be a Condition (with other resources referenced in the evidence.detail), or a Procedure. \"For systems that need to know which was the primary diagnosis, these will be marked with the standard extension primaryDiagnosis (which is a sequence value rather than a flag, 1 = primary diagnosis).\"","No","N/A"]
[null,"Encounter","Encounter principal diagnosis","The principal diagnosis is the \"condition established after study to be chiefly responsible for occasioning the admission of the patient …\" (Source: ICD-10-CM Official Guidelines for Coding and Reporting, FY2019, pp. 107). All institutional claims require a principal diagnosis whether they are inpatient or outpatient facilities.","No","N/A"]
[null,"Encounter","Hospital encounter discharge disposition","Category or kind of location after discharge.","No","N/A"]
[null,"Encounter","Encounter location address","The location where the encounter takes place.","No","N/A"]
[null,"Encounter","Expected source(s) of payment for this encounter","The type of coverage: social program, medical plan, accident coverage (workers compensation, auto), group health or payment by an individual or organization.","No","N/A"]
[null,"Encounter","Encounter chief complaint","Role that this diagnosis has within the encounter (e.g. chief complaint).","No","N/A"]

{"sheet":"Immunizations","index":4,"n_rows":8,"n_cols":33,"rows_kept":8,"merged":[[1,6,4,6],[1,7,4,7],[1,8,4,8],[1,9,4,9],[1,10,4,10],[1,11,4,11],[1,12,4,12],[1,13,4,13],[1,14,4,14],[1,15,4,15],[1,16,4,16],[1,17,4,17],[1,18,4,18],[1,19,4,19],[1,20,4,20],[1,21,4,21],[1,22,4,22],[1,23,4,23],[1,24,4,24],[1,25,4,25],[1,26,4,26],[1,27,4,27],[1,28,4,28],[1,29,4,29],[1,30,4,30],[1,31,4,31],[1,32,4,32]]}
[null,"DATA CLASS       Data Class Name","DATA ELEMENT  (1…m Data Element(s) per Data Class)                         Data Element Name","Data Element Description","Similar or related DE's in USCDI","If Yes, why DE considered separately?","USE CASE                                                                                                                               Describe the main use cases to support adoption of the DE into USCDI","Estimate # of stakeholders who would capture, access, use or exchange this DE or DC*","Link to use case project page","Please describe the additional use case:*","FOR ADD USE CASE - Estimate # of stakeholders who would capture, access, use or exchange this DE or DC*","FOR ADD USE CASE -Link URL ","Attachment describing this (unclear if main or ADD Use Case(s)) use case","Does this data element support the following aims in healthcare?* (Check all that Apply)","MATURITY                                    Does a vocabulary, terminology, content, or structural standard exist for this data element? (e.g., SNOMED CT, LOINC, RxNorm) * (select one)","If yes, please cite the applicable standard*","If yes, link URL","Are there additional technical specifications such as an implementation guide (IG) or profile using this data element? (e.g., HL7® FHIR® US Core Implementation Guide v3.1.0 based on FHIR R4)  ","If yes, please cite the relevant technical specification(s)*","Which of the following best describes the use of this data element?* (select one)","Please cite supporting artifacts*","Link URL","Attachment","Has this data element been electronically exchanged with external organizations or individuals (including patients)?* (select one)","If yes, with how many outside entities has this been exchanged?* ","Please cite supporting artifacts:*","Supporting Link","Attachment","CHALLENGES                                      Describe any restrictions on the standardization of this data element \n(e.g., proprietary code).*","Describe any restrictions on the use of this data element (e.g., licensing, user fees).*","Describe any privacy and security concerns with the use and exchange of this data element.*","Please provide an estimate of overall burden to implement. Overall estimate of burden to implement, including those not affected by the primary use case(s) (i.e., impact to broader healthcare community for specialty-specific data element submission.)*","Please provide information on other challenges to implementation"]
[null,"Immunizations","Immunization Code","\t\n\nThe code for the vaccine that was administered or was to be administered.","Yes","The current element of immunizations does not specifically state that this is used to capture the code or name of the immunization administered. Suggest renaming the current element of \"Immunizations\" to \"Immunization Code\"","Actively monitoring diseases, making decisions about public health threats, identifying trends in healthcare services utilization and other public health matters depend on accessible and accurate data. EHRs are a data source that can 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 more rapid disease detection, tracking, and treatment and innovation in healthcare delivery. \n\nImmunization information, including the coded identification of the vaccine administered, date the immunization is administered, immunization status and the reason why an immunization was not performed are important to multiple public health reporting and research use cases to track and analyze information about treatment for various health conditions. \n\nThe Making EHR Data More Available for Research and Public Health (MedMorph) project has the goal to create a reliable, scalable, and interoperable method to get electronic health record data for multiple public health and research scenarios (use cases). MedMorph has identified Healthcare Surveys, Electronic Case Reporting (eCR), Research (PCORnet), and Multiple Chronic Conditions (MCC) eCare Plan (for Immunization Code only) use cases that support the adoption of these data elements. These specific use cases are described in more depth on their respective web pages. ","All 50 states participate in one or more of the public health use cases that exchange these data elements. Up to 14 territorial or city jurisdictions also participate in one of these public health use cases and use these data elements.\n\nApproximately 420,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.                                            \nThere 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. The vast majority of these exchanges include immunization data, including the data elements requested for USCDI consideration here. ","MedMorph Project Page: https://www.cdc.gov/csels/phio/making-ehr-data-more-available.html\n\nHepatitis C Case Report Form: https://www.cdc.gov/hepatitis/pdfs/HepatitisCaseRprtForm.pdf\n\nPCORnet: https://pcornet.org/\n\nMCC eCare Plan: https://confluence.hl7.org/display/PC/Multiple+Chronic+Conditions+%28MCC%29+eCare+Plan","A foundational goal of MedMorph is generalizability beyond the 10 use cases that are actively informing the MedMorph project, in order 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 these data elements. ",{"$nulls":3},"Improving the health of populations ","Yes","Immunization Code: CVX: Vaccines Administered 2.16.840.1.113762.1.4.1010.6\n\nImmunization Code: National Drug Codes (NDC)\n\nImmunization Status: FHIR Immunization Status Codes\n\nImmunization Administered Date: FHIR datatypes: dateTime, String\n\nReason Immunization Not Performed: FHIR Immunization Status Reason Codes","Immunization Code: https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1010.6/expansion\n\nImmunization Code:  http://www2a.cdc.gov/vaccines/iis/iisstandards/ndc_tableaccess.asp\n\nImmunization Status Codes: http://hl7.org/fhir/ValueSet/immunization-status\n\nImmunization Administered Date: https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-immunization-definitions.html#Immunization.occurrence[x]\n\nReason Immunization Not Performed: http://hl7.org/fhir/R4/valueset-immunization-status-reason.html","Yes","HL7 FHIR US Core Implementation Guide v3.1.1: https://www.hl7.org/fhir/us/core/index.html\n\nC-CDA (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\n\nHL7 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\n\nHL7 FHIR® Implementation Guide: Common Data Models Harmonization FHIR Implementation Guide (Release 0.1.0): http://hl7.org/fhir/us/cdmh/2019May/\n\nHL7 FHIR® Implementation Guide: Electronic Case Reporting (eCR) - US Realm: http://hl7.org/fhir/us/ecr/STU1/\n\nHL7 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","Extensively used in production environments","Widely available in EHR systems.\n\nThese data elements exist in FHIR with a FHIR Maturity level of 3 for the Immunization Resource.\n\nThe Clinical Vaccines Administered (CVX) and National Drug Code (NDC) standards are included in the ISA with an adoption level of 5 in production implementations.\n\nPart of Core EHR Certification since at least 2014\n\nIHE Connectathons 2019-2020 (CDA; as part of National Health Care Surveys IGs)           ","http://hl7.org/fhir/immunization.html\n\nhttps://www.healthit.gov/isa/representing-immunizations-administered\n\nhttps://fhir.epic.com/Specifications?api=21\n\nhttps://developer.allscripts.com/FHIR?PageTitle=Resources\n\nhttps://www.healthit.gov/sites/default/files/2014_test_methods/2014_edition_test_methods_archived.zip",null,"Yes","5 or more. This data element has been tested at scale between multiple different production environments to support the majority of anticipated stakeholders.","IHE Connectathons 2019-2020 (CDA; as part of National Health Care Surveys IGs)                                                                                     ONC Interoperability Standards Advisory - Sending Health Care Survey Information to Public Health Agencies - see:                                            \n\nCare Connect API, INTEROPen, NHS Digital","https://www.healthit.gov/isa/sending-health-care-survey-information-public-health-agencies \n\nhttps://nhsconnect.github.io/CareConnectAPI/api_medication_immunization.html",null,"None","None","None","Low.\nProviders capture immunization information as a basic component of patient care. \nSeveral existing IGs, as listed, require exchange of this data element. Several existing IGs, as listed, require exchange of this data element. The Promoting Interoperability Programs Objective 8 - Public Health and Clinical Data Registry Reporting, Measures 1: Immunization Registry Reporting, 2: Syndromic Surveillance Reporting, 3 -: Electronic Case Reporting and 4: Public Health Registry Reporting all require these data elements.\n\nThis information is routinely communicated in HL7 CDA Documents and some FHIR API transactions.","None"]
[null,"Immunizations","Immunization Status","Indicates the current status of the immunization event.","No"]
[null,"Immunizations","Immunization Administered Date","The date the vaccine was administered or was to be administered.","No"]
[null,"Immunizations","Reason Immunization Not Performed","Indicates the reason the immunization event was not performed.","No"]
[]
[]
[{"$nulls":10},"  "]

{"sheet":"Laboratory","index":5,"n_rows":8,"n_cols":33,"rows_kept":8,"merged":[[1,6,4,6],[1,7,4,7],[1,8,4,8],[1,9,4,9],[1,10,4,10],[1,11,4,11],[1,12,4,12],[1,13,4,13],[1,14,4,14],[1,15,4,15],[1,16,4,16],[1,17,4,17],[1,18,4,18],[1,19,4,19],[1,20,4,20],[1,21,4,21],[1,22,4,22],[1,23,4,23],[1,24,4,24],[1,25,4,25],[1,26,4,26],[1,27,4,27],[1,28,4,28],[1,29,4,29],[1,30,4,30],[1,31,4,31],[1,32,4,32]]}
[null,"DATA CLASS       Data Class Name","DATA ELEMENT  (1…m Data Element(s) per Data Class)                         Data Element Name","Data Element Description","Similar or related DE's in USCDI","If Yes, why DE considered separately?","USE CASE                                                                                                                               Describe the main use cases to support adoption of the DE into USCDI","Estimate # of stakeholders who would capture, access, use or exchange this DE or DC*","Link to use case project page","Please describe the additional use case:*","FOR ADD USE CASE - Estimate # of stakeholders who would capture, access, use or exchange this DE or DC*","FOR ADD USE CASE -Link URL ","Attachment describing this (unclear if main or ADD Use Case(s)) use case","Does this data element support the following aims in healthcare?* (Check all that Apply)","MATURITY                                    Does a vocabulary, terminology, content, or structural standard exist for this data element? (e.g., SNOMED CT, LOINC, RxNorm) * (select one)","If yes, please cite the applicable standard*","If yes, link URL","Are there additional technical specifications such as an implementation guide (IG) or profile using this data element? (e.g., HL7® FHIR® US Core Implementation Guide v3.1.0 based on FHIR R4)  ","If yes, please cite the relevant technical specification(s)*","Which of the following best describes the use of this data element?* (select one)","Please cite supporting artifacts*","Link URL","Attachment","Has this data element been electronically exchanged with external organizations or individuals (including patients)?* (select one)","If yes, with how many outside entities has this been exchanged?* ","Please cite supporting artifacts:*","Supporting Link","Attachment","CHALLENGES                                      Describe any restrictions on the standardization of this data element \n(e.g., proprietary code).*","Describe any restrictions on the use of this data element (e.g., licensing, user fees).*","Describe any privacy and security concerns with the use and exchange of this data element.*","Please provide an estimate of overall burden to implement. Overall estimate of burden to implement, including those not affected by the primary use case(s) (i.e., impact to broader healthcare community for specialty-specific data element submission.)*","Please provide information on other challenges to implementation"]
[null,"Laboratory Tests","Laboratory Test/Panel Code","The test that was performed.","Yes","The current element of Tests does not specifically state that this is used to capture the code or name of the laboratory test performed. Suggest renaming the current element of \"Tests\" to \"Test/Panel Code\"","Actively monitoring diseases, making decisions about public health threats, identifying trends in healthcare services utilization and other public health matters depend on accessible and accurate data. EHRs are a data source that can 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 more rapid disease detection, tracking, and treatment and innovation in healthcare delivery. \n\nLaboratory information, including the test code, test performed date, result status, result value and the result date, are important to multiple public health reporting and research use cases to track and analyze information about treatment for various health conditions. \n\nThe Making EHR Data More Available for Research and Public Health (MedMorph)  project's goal is to create a reliable, scalable, and interoperable method to get electronic health record data for multiple public health and research scenarios (use cases). MedMorph has identified Cancer Reporting, Healthcare Surveys, Hepatitis C Reporting, electronic Initial Case Reporting (eICR), PCORnet, and Birth Defect Reporting use cases that support the adoption of these data elements. These specific use cases are described in more depth on their respective web pages. ","All 50 states participate in one or more of the public health use cases that exchange these data element. Up to 14 territorial or city jurisdictions also participate in one of these public health use cases and use these data elements. \n\nAll hospitals and physicians who diagnose or treat cancer are required to provide cancer related laboratory information to state cancer registries. \n\nApproximately 420,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.                                            \nThere 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. The vast majority of these exchanges include full sets of medication data, including the data elements requested for USCDI consideration here.","MedMorph Project Page: https://www.cdc.gov/csels/phio/making-ehr-data-more-available.html\n\nCancer Reporting: https://www.cdc.gov/cancer/npcr/\n\nHealthcare Surveys: https://www.cdc.gov/nchs/dhcs/nhcs_registry_landing.htm\n\nHepatitis C Reporting: https://www.cdc.gov/hepatitis/pdfs/HepatitisCaseRprtForm.pdf\n\neICR: https://www.cdc.gov/ecr/index.html \n\nPCORnet: https://pcornet.org/\n\nBirth Defect Reporting: https://www.cdc.gov/nchs/nvss/births.htm","A foundational goal of MedMorph is generalizability beyond the 10 use cases that are actively informing the MedMorph project, in order 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 these data elements. ",{"$nulls":3},"Improving the health of populations ","Yes","Laboratory Test/Panel Code: LOINC Codes\n\nLaboratory Test Performed Date: FHIR dateTime, Period, Timing,  Instant\n\nLaboratory Result Status: FHIR Observation Status\n\nLaboratory Result Value: FHIR Quantity|CodeableConcept|string|boolean|integer|Range|Ratio|SampledData|time|dateTime|Period","Laboratory Test/Panel Code: http://loinc.org\n\nLaboratory Test Performed Date: http://hl7.org/fhir/observation-definitions.html#Observation.effective_x_\n\nLaboratory Result Status: http://hl7.org/fhir/valueset-observation-status.html\n\nLaboratory Result Value: http://hl7.org/fhir/observation-definitions.html#Observation.value_x_","Yes","HL7 FHIR US Core Implementation Guide v3.1.1: https://www.hl7.org/fhir/us/core/index.html\n\nC-CDA (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\n\nHL7 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\n\nHL7 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\n\nHL7 FHIR® Implementation Guide: Electronic Case Reporting (eCR) - US Realm: http://hl7.org/fhir/us/ecr/STU1/\n\nHL7 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\n\nHL7 FHIR® Implementation Guide: Common Data Models Harmonization FHIR Implementation Guide (Release 0.1.0): http://hl7.org/fhir/us/cdmh/2019May/\n\nHL7 CDA® R2 Implementation Guide: Ambulatory and Hospital Healthcare Provider Reporting to Birth Defect Registries Release 1 , STU 2 -US Realm: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=428\n\nHL7 FHIR® Implementation Guide: Birth Defect Reporting Implementation Guide 0.1.0: https://build.fhir.org/ig/HL7/fhir-birthdefectsreporting-ig/index.html","Extensively used in production environments","Widely available in EHR systems.\n\nPart of Core EHR Certification since at least 2014 (is this correct? Need confirmation) \nSpecified in Meaningful Use/Promoting Interoperability since Stage 1 (is this correct? Need confirmation)\nPart of EHR Certification for Transmission to Cancer Registries (2015 and 2014 Editions)\n\nThese data elements exist in FHIR with a FHIR Maturity level of Normative for the Observation Resource.\n\nLOINC is included in the ISA with an adoption level of 3 in production implementations for representing laboratory tests. SNOMED CT is included in the ISA with an adoption level of 1 in production implementations for representing laboratory tests.\n\nIHE Connectathons 2010-2020 (CDA; as part of Cancer Reporting IGs)\nHIMSS Interoperability Showcase 2010-19 (CDA; as part of Cancer Reporting IGs)\nPublic Health Informatics Conference Interoperability Showcase 2014, 2016, 2018 (CDA; as part of Cancer Reporting IGs)\nNACCHO 360X Interoperability Demonstrations, 2020 (CDA; as part of Cancer Reporting IGs)\n\nIHE Connectathons 2019-2020 (CDA; as part of National Health Care Surveys IGs)                     ","https://fhir.epic.com/Specifications?api=998\n\nhttp://hl7.org/fhir/observation.html\n\nhttps://www.healthit.gov/isa/section/laboratory\n\nhttps://www.healthit.gov/test-method/transmission-cancer-registries#test_procedure\n\nhttps://www.healthit.gov/sites/default/files/2014_test_methods/2014_edition_test_methods_archived.zip",null,"Yes","5 or more. This data element has been tested at scale between multiple different production environments to support the majority of anticipated stakeholders. ","IHE Connectathons 2010-2020 (CDA; as part of Cancer Reporting IGs)\nHIMSS Interoperability Showcase 2010-19 (CDA; as part of Cancer Reporting IGs)\nPublic Health Informatics Conference Interoperability Showcase 2014, 2016, 2018 (CDA; as part of Cancer Reporting IGs)\nNACCHO 360X Interoperability Demonstrations, 2020 (CDA; as part of Cancer Reporting IGs)\n\n\nIHE Connectathons 2019-2020 (CDA; as part of National Health Care Surveys IGs)                                                                                     ONC Interoperability Standards Advisory - Sending Health Care Survey Information to Public Health Agencies - see:                                      https://www.healthit.gov/isa/sending-health-care-survey-information-public-health-agencies         ","https://chpl.healthit.gov/#/search: 170.315 (f)(4): Transmission to Cancer Registries\nRetired | 170.314 (f)(5): Optional - ambulatory setting only - cancer case information\nRetired | 170.314 (f)(6): Optional - ambulatory setting only - transmission to cancer registries)",null,"None","None","None","Low.\n\nAll providers need to capture laboratory information as a basic component of patient care. \nSeveral existing IGs, as listed, require exchange of this data element. The Promoting Interoperability Programs Objective 8 - Public Health and Clinical Data Registry Reporting, Measures 1: Immunization Registry Reporting, 2: Syndromic Surveillance Reporting, 3 -: Electronic Case Reporting and 4: Public Health Registry Reporting all require these data elements.\n \nThis information is routinely communicated in HL7 CDA Documents and some FHIR API transactions","None"]
[null,"Laboratory Tests","Laboratory Test Performed Date","The date or time period the test was performed.","No"]
[null,"Laboratory Values/Results","Laboratory Result Status","The status of the laboratory result value.","No"]
[null,"Laboratory Values/Results","Laboratory Result Value","The laboratory result value.","Yes","The current element of Values/Results does not specifically state that this is used to capture the value of the laboratory test result. Suggest renaming the current element of \"Values/Results\" to \"Result Value\"."]
[null,"Laboratory Values/Results","Laboratory Result Date/Time",null,"No"]
[]
[{"$nulls":10},"  "]

{"sheet":"Medications","index":6,"n_rows":12,"n_cols":33,"rows_kept":12,"merged":[[1,6,11,6],[1,7,11,7],[1,8,11,8],[1,9,11,9],[1,10,11,10],[1,11,11,11],[1,12,11,12],[1,13,11,13],[1,14,11,14],[1,15,11,15],[1,16,11,16],[1,17,11,17],[1,18,11,18],[1,19,11,19],[1,20,11,20],[1,21,11,21],[1,22,11,22],[1,23,11,23],[1,24,11,24],[1,25,11,25],[1,26,11,26],[1,27,11,27],[1,28,11,28],[1,29,11,29],[1,30,11,30],[1,31,11,31],[1,32,11,32]]}
[null,"DATA CLASS       Data Class Name","DATA ELEMENT  (1…m Data Element(s) per Data Class)                         \nData Element Name","Data Element Description","Similar or related D E's in USCDI","Why D E considered separately?","USE CASE                                                                                                                               Describe the main use cases to support adoption of the DE into USCDI","Estimate # of stakeholders who would capture, access, use or exchange this DE or DC","Link to use case project page","Please describe the additional use case:*","FOR ADD USE CASE - Estimate # of stakeholders who would capture, access, use or exchange this DE or DC","FOR ADD USE CASE -Link URL ","Attachment describing this (unclear if main or ADD Use Case(s)) use case","Does this data element support the following aims in healthcare?","MATURITY                                    Does a vocabulary, terminology, content, or structural standard exist for this data element? (e.g., SNOMED CT, LOINC, RxNorm) * (select one)","If yes, please cite the applicable standard","If yes, link URL","Are there additional technical specifications such as an implementation guide (IG) or profile using this data element? (e.g., HL7® FHIR® US Core Implementation Guide v3.1.0 based on FHIR R4)  ","If yes, please cite the relevant technical specification(s)*","Which of the following best describes the use of this data element?* (select one)","Please cite supporting artifacts","Link URL","Attachment","Has this data element been electronically exchanged with external organizations or individuals (including patients)?* (select one)","If yes, with how many outside entities has this been exchanged?* ","Please cite supporting artifacts:*","Supporting Link","Attachment","CHALLENGES                                      Describe any restrictions on the standardization of this data element \n(e.g., proprietary code).*","Describe any restrictions on the use of this data element (e.g., licensing, user fees).*","Describe any privacy and security concerns with the use and exchange of this data element.*","Please provide an estimate of overall burden to implement. Overall estimate of burden to implement, including those not affected by the primary use case(s) (i.e., impact to broader healthcare community for specialty-specific data element submission.)*","Please provide information on other challenges to implementation"]
[null,"Medications","Date Medication Prescribed","The date/time when the prescription was initially written or authored","No","N/A","Actively monitoring diseases, making decisions about public health threats, identifying trends in healthcare services utilization and other public health matters depend on accessible and accurate patient data. EHRs are a data source that can 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 more rapid disease detection, tracking, and treatment and innovation in healthcare delivery. \n\nMedication information, including the date the medication is prescribed or administered, coded identification, and dosage of the medication prescribed or administered are important to multiple public health reporting and research use cases to track and analyze information about treatment for various health conditions. The reason code for the medication provides information to identify which particular condition the medication was used to treat. \n\nThe Making EHR Data More Available for Research and Public Health (MedMorph) project's goal is to create a reliable, scalable, and interoperable method to get electronic health record data for multiple public health and research scenarios (use cases). MedMorph has identified Cancer Registry Reporting, Healthcare Surveys, Electronic Initial Case Reporting (eCR), Hepatitis C Reporting, and Research (PCORnet) use cases that support the adoption of some or all of these data elements. These specific use cases are described in more depth on their respective web pages. ","All 50 states participate in one or more of the public health use cases that exchange these data element. Up to 14 territorial or city jurisdictions also participate in one of these public health use cases and use these data elements. \n\nAll hospitals and physicians who diagnose or treat cancer are required to provide cancer related medication (treatment) information to state cancer registries. \n\nApproximately 420,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.                                            \nThere 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. The vast majority of these exchanges include full sets of medication data, including the data elements requested for USCDI consideration here.","https://www.cdc.gov/csels/phio/making-ehr-data-more-available.html\n\nhttps://www.cdc.gov/cancer/npcr/\n\nhttps://www.cdc.gov/hepatitis/pdfs/HepatitisCaseRprtForm.pdf\n\nhttps://www.cdc.gov/nchs/dhcs/nhcs_registry_landing.htm\n\nhttps://www.cdc.gov/ecr/index.html\n\nhttps://pcornet.org/","A foundational goal of MedMorph is generalizability beyond the 10 use cases that are actively informing the MedMorph project, in order 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 these data elements. \n","  ",null,null,"Improving the health of populations ","Yes","Date Medication Prescribed and Date Medication Administered:  dateTime Data Type (FHIR)\n\nMedication Prescribed Code and Medication Administered Code: RxNorm\n\nMedication Prescribed Dose Units and Medication Administration Dose Units: UCUM?\n\n","Date Medication Prescribed and Date Medication Administered: http://hl7.org/fhir/datatypes.html#dateTime\n\nMedication Prescribed Code and Medication Administered Code: https://www.nlm.nih.gov/research/umls/rxnorm/index.html","Yes","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)\n\nHL7 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)\n\nC-CDA (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) \n\nHL7 FHIR® US Core Implementation Guide STU3 Release 3.1.1 (https://www.hl7.org/fhir/us/core/index.html)\n\nHL7 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)\n\nHL7 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)\n","Extensively used in production environments","Widely available in EHR systems.\n\nPart of Core EHR Certification since at least 2014 (is this correct? Need confirmation) \nSpecified in Meaningful Use/Promoting Interoperability since Stage 1 (is this correct? Need confirmation)\nPart of EHR Certification for Transmission to Cancer Registries (2015 and 2014 Editions)\n\nThese data elements exist in FHIR with a FHIR Maturity level of 2 for MedicationAdministration and 3 for MedicationRequest\n\nIHE Connectathons 2010-2020 (CDA; as part of Cancer Reporting IGs)\nHIMSS Interoperability Showcase 2010-19 (CDA; as part of Cancer Reporting IGs)\nPublic Health Informatics Conference Interoperability Showcase 2014, 2016, 2018 (CDA; as part of Cancer Reporting IGs)\nNACCHO 360X Interoperability Demonstrations, 2020 (CDA; as part of Cancer Reporting IGs)\n\nIHE Connectathons 2019-2020 (CDA; as part of National Health Care Surveys IGs)                                     \n","https://fhir.epic.com/Specifications?api=996\nhttps://fhir.cerner.com/millennium/r4/medications/medication-request/\nhttps://developer.allscripts.com/FHIR?PageTitle=Resources\nhttps://api.evident.com/dstu2/medication-order\n\nhttps://www.healthit.gov/test-method/transmission-cancer-registries#test_procedure\n\nhttps://www.healthit.gov/sites/default/files/2014_test_methods/2014_edition_test_methods_archived.zip",null,"Yes","5 or more. This data element has been tested at scale between multiple different production environments to support the majority of anticipated stakeholders. ","IHE Connectathons 2010-2020 (CDA; as part of Cancer Reporting IGs)\nHIMSS Interoperability Showcase 2010-19 (CDA; as part of Cancer Reporting IGs)\nPublic Health Informatics Conference Interoperability Showcase 2014, 2016, 2018 (CDA; as part of Cancer Reporting IGs)\nNACCHO 360X Interoperability Demonstrations, 2020 (CDA; as part of Cancer Reporting IGs)\n\nIHE Connectathons 2019-2020 (CDA; as part of National Health Care Surveys IGs)                                                                                     ONC Interoperability Standards Advisory - Sending Health Care Survey Information to Public Health Agencies - see:                                      https://www.healthit.gov/isa/sending-health-care-survey-information-public-health-agencies                                                Need eCR info added\n\nOthers through MU/PI? \nReview/input needed","https://chpl.healthit.gov/#/search: 170.315 (f)(4): Transmission to Cancer Registries\nRetired | 170.314 (f)(5): Optional - ambulatory setting only - cancer case information\nRetired | 170.314 (f)(6): Optional - ambulatory setting only - transmission to cancer registries)",null,"None","None","None","Low.\nAll providers need to capture medication prescription and administration information as a basic component of patient care. \nSeveral existing IGs, as listed, require exchange of this data element. The Promoting Interoperability Programs Objective 8 - Public Health and Clinical Data Registry Reporting, Measures 1: Immunization Registry Reporting, 2: Syndromic Surveillance Reporting, 3 -: Electronic Case Reporting and 4: Public Health Registry Reporting all require these data elements.\n \nThis information is routinely communicated in HL7 CDA Documents and some FHIR API transactions.\n","None"]
[null,"Medications","Medication Prescribed Code","A code (or set of codes) that specify this medication, or a textual description if no code is available. ","Yes","USCDI data element is simply \"medication\". There is no indication of whether it is  prescribed, administered, etc. In FHIR US Core, there is a distinction between \"Medication\" and \"Medication Request\"; and \"Medication Administration\" in base FHIR. We believe both concepts, prescribed and administered, should be explicitly included in USCDI."]
[null,"Medications","Medication Prescribed Dose","Indicates the amount of medication per dose that is to be used by the patient","No"]
[null,"Medications","Medication Prescribed Dose Units","Indicates the units of measure associated with the amount of medication per dose that is to be used by the patient","No"]
[null,"Medications","Medication Prescribed Reason Reference","Reference to the condition or observation that supports why the prescription is being written","No","N/A"]
[null,"Medications","Date Medication Administered","A specific date/time or interval of time during which the administration took place (or did not take place, when the 'notGiven' attribute is true).","No","N/A"]
[null,"Medications","Medication Administered Code","A code (or set of codes) that specify the medication that was administered","Yes","USCDI data element is simply \"medication\". There is no indication of whether it is prescribed, administered, etc. In FHIR US Core, there is a distinction between \"Medication\" and \"Medication Request\"; and \"Medication Administration\" in base FHIR. We believe both concepts, prescribed and administered, should be explicitly included in USCDI."]
[null,"Medications","Medication Administered Reason Reference","Reference to a condition that is the reason for the medication request.","No","N/A"]
[null,"Medications","Medication Administered Performer","Indicates who or what performed the medication administration and how they were involved.","No","N/A"]
[null,"Medications","Medication Administration Dose","The amount of the medication given at one administration event.","No","N/A"]
[null,"Medications","Medication Administration Dose Units","The units of measure associated with the amount of medication given at one administration event","No","N/A"]

{"sheet":"Mother's Delivery Info","index":7,"n_rows":3,"n_cols":33,"rows_kept":3,"merged":[[1,6,2,6],[1,7,2,7],[1,8,2,8],[1,9,2,9],[1,10,2,10],[1,11,2,11],[1,12,2,12],[1,13,2,13],[1,14,2,14],[1,15,2,15],[1,16,2,16],[1,17,2,17],[1,18,2,18],[1,19,2,19],[1,20,2,20],[1,21,2,21],[1,22,2,22],[1,23,2,23],[1,24,2,24],[1,25,2,25],[1,26,2,26],[1,27,2,27],[1,28,2,28],[1,29,2,29],[1,30,2,30],[1,31,2,31],[1,32,2,32]]}
[null,"DATA CLASS       Data Class Name","DATA ELEMENT  (1…m Data Element(s) per Data Class)                         Data Element Name","Data Element Description","Similar or related D E's in USCDI","If Yes, why DE considered separately?","USE CASE                                                                                                                               Describe the main use cases to support adoption of the DE into USCDI","Estimate # of stakeholders who would capture, access, use or exchange this DE or DC*","Link to use case project page","Please describe the additional use case:*","FOR ADD USE CASE - Estimate # of stakeholders who would capture, access, use or exchange this DE or DC*","FOR ADD USE CASE -Link URL ","Attachment describing this (unclear if main or ADD Use Case(s)) use case","Does this data element support the following aims in healthcare?* (Check all that Apply)","MATURITY                                    Does a vocabulary, terminology, content, or structural standard exist for this data element? (e.g., SNOMED CT, LOINC, RxNorm) * (select one)","If yes, please cite the applicable standard*","If yes, link URL","Are there additional technical specifications such as an implementation guide (IG) or profile using this data element? (e.g., HL7® FHIR® US Core Implementation Guide v3.1.0 based on FHIR R4)  ","If yes, please cite the relevant technical specification(s)*","Which of the following best describes the use of this data element?* (select one)","Please cite supporting artifacts*","Link URL","Attachment","Has this data element been electronically exchanged with external organizations or individuals (including patients)?* (select one)","If yes, with how many outside entities has this been exchanged?* ","Please cite supporting artifacts:*","Supporting Link","Attachment","CHALLENGES                                      Describe any restrictions on the standardization of this data element \n(e.g., proprietary code).*","Describe any restrictions on the use of this data element (e.g., licensing, user fees).*","Describe any privacy and security concerns with the use and exchange of this data element.*","Please provide an estimate of overall burden to implement. Overall estimate of burden to implement, including those not affected by the primary use case(s) (i.e., impact to broader healthcare community for specialty-specific data element submission.)*","Please provide information on other challenges to implementation"]
[null,"Mother's Delivery Information","Number of Prenatal Visits","The total number of prenatal visits for the mother. ","No",null,"Monitoring disease and making decisions about public health threats depends on accessible and accurate data. EHRs are a data source with 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.       \n\nThe details of a delivery are crucial for providing the best possible post-natal care to the mother and infant. As well, after delivery, public health needs to capture this data as part of birth certification, fetal death reporting and birth defect reporting. In particular, birth certification forms the basis of the patient census required by a large number of other public health programs including newborn screening, birth defect reporting and immunization registries making it critical that birth certification is as automated, timely and accurate as possible.\n\nThe 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. 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.","Every year there are approximately 3.7 million births in the United States. Consumption of this data is widespread. Every jurisdiction in the country captures birth certification information and immunization administration. Most also capture birth defects and fetal deaths. Healthcare systems which provide care for expectant mothers should be collecting this data.","https://www.cdc.gov/csels/phio/making-ehr-data-more-available.html\nhttps://www.cdc.gov/nchs/nvss/births.htm\nhttps://www.cdc.gov/ncbddd/birthdefects/index.html",{"$nulls":4},"More than 1 but not all","Yes","LOINC codes exist for each of the proposed data elements:\n68493-6 - Prenatal visits for this pregnancy #\n69044-6 - Date first prenatal visit","https://loinc.org/","Yes","Vital Records Common Profiles Library FHIR IG - http://build.fhir.org/ig/HL7/fhir-vr-common-ig/branches/master/index.html\nVital Records Birth and Fetal Death Reporting - https://build.fhir.org/ig/HL7/fhir-bfdr/index.html\nHL7 Version 2.6 Implementation Guide: Vital Records Birth and Fetal Death Reporting, Release 1 STU Release 2 - US Realm https://www.hl7.org/implement/standards/product_brief.cfm?product_id=320\n\nHL7 CDA® R2 Implementation Guide: Birth and Fetal Death Reporting, Release 1, STU Release 2 - US Realm -https://www.hl7.org/implement/standards/product_brief.cfm?product_id=387\n\nIHE Quality, Research and Public Health Technical Framework Supplement – Birth and Fetal Death Reporting-Enhanced (BFDR-E) Revision 3.1 - https://www.ihe.net/uploadedFiles/Documents/QRPH/IHE_QRPH_Suppl_BFDR-E.pdf\n\nBirth Defect Reporting FHIR IG - https://build.fhir.org/ig/HL7/fhir-birthdefectsreporting-ig/index.html\n\nHL7 CDA® R2 Implementation Guide: Ambulatory and Hospital Healthcare Provider Reporting to Birth Defect Registries Release 1 , STU 2 -US Realm - https://www.hl7.org/implement/standards/product_brief.cfm?product_id=428\n","In limited use in production environments","This data is exchanged routinely as part of birth certification, fetal death reporting and birth defect reporting, however these workflows typically are executed on paper or via flat files rather than through electronic interoperability.\nEPIC FHIR APIs for patient, vitals, obstetric details (DSTU2, DSTU3, R4)\nIn production use:\nEPIC stork module (obstetrics) for birth reporting","Facility worksheet information:\nhttps://www.cdc.gov/nchs/data/dvs/facility-worksheet-2016-508.pdf\nhttps://www.cdc.gov/nchs/data/dvs/fetal-death-mother-worksheet-english-2019-508.pdf\nEPIC stork module (obstetrics) for birth reporting: https://www.epic.com/software#PatientEngagement\nEPIC FHIR APIs for patient, vitals, obstetric details:\nhttps://fhir.epic.com/Specifications?api=932\nhttps://fhir.epic.com/Specifications?api=968\nhttps://fhir.epic.com/Specifications?api=966\n",null,"Yes","5 or more","IHE Connectathon integration profiles for BFDR-E (2013 - 2020)\n\nHL7 FHIR Connectathon results (Sept 2020): birth and fetal death reporting results testing between electronic birth registration system vendors (FHIR)\n\nNACCHO 360X Interoperability Demonstrations for Birth and Fetal Death reporting 2020 between NextGen and two state electronic birth registrations system vendors using FHIR.\n\nHIMSS Interoperability showcase (2018 – 2019)","Found in 'New Search', filter by 'Select an integration profile = Birth and Fetal Death Reporting-Enhanced'  https://connectathon-results.ihe.net/view_result.php?rows=company&columns=actor&title=integration_profile\n\nhttps://confluence.hl7.org/display/FHIR/2020-09+Public+Health+Track\nhttps://www.interoperabilityshowcase.org/",null,"None ","None","No concerns over and above the typically privacy and security considerations associated with any health related data.","These data elements are straightforward in nature and should not present a large burden to implement provided the EHR system is capturing the data as part of caring for the woman.","When using FHIR there may be associated costs with 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.  "]
[null,"Mother's Delivery Information","Date of First Prenatal Care Visit","The date of the first prenatal care visit for this pregnancy. A prenatal visit is where a physician or other health care professional examined and/or counseled the pregnant woman for the pregnancy.","No"]

{"sheet":"Newborn's Delivery Info","index":8,"n_rows":3,"n_cols":33,"rows_kept":3,"merged":[[1,6,2,6],[1,7,2,7],[1,8,2,8],[1,9,2,9],[1,10,2,10],[1,11,2,11],[1,12,2,12],[1,13,2,13],[1,14,2,14],[1,15,2,15],[1,16,2,16],[1,17,2,17],[1,18,2,18],[1,19,2,19],[1,20,2,20],[1,21,2,21],[1,22,2,22],[1,23,2,23],[1,24,2,24],[1,25,2,25],[1,26,2,26],[1,27,2,27],[1,28,2,28],[1,29,2,29],[1,30,2,30],[1,31,2,31],[1,32,2,32]]}
[null,"DATA CLASS       Data Class Name","DATA ELEMENT  (1…m Data Element(s) per Data Class)                         Data Element Name","Data Element Description","Similar or related D E's in USCDI","If Yes, why DE considered separately?","USE CASE                                                                                                                               Describe the main use cases to support adoption of the DE into USCDI","Estimate # of stakeholders who would capture, access, use or exchange this DE or DC*","Link to use case project page","Please describe the additional use case:*","FOR ADD USE CASE - Estimate # of stakeholders who would capture, access, use or exchange this DE or DC*","FOR ADD USE CASE -Link URL ","Attachment describing this (unclear if main or ADD Use Case(s)) use case","Does this data element support the following aims in healthcare?* (Check all that Apply)","MATURITY                                    Does a vocabulary, terminology, content, or structural standard exist for this data element? (e.g., SNOMED CT, LOINC, RxNorm) * (select one)","If yes, please cite the applicable standard*","If yes, link URL","Are there additional technical specifications such as an implementation guide (IG) or profile using this data element? (e.g., HL7® FHIR® US Core Implementation Guide v3.1.0 based on FHIR R4)  ","If yes, please cite the relevant technical specification(s)*","Which of the following best describes the use of this data element?* (select one)","Please cite supporting artifacts*","Link URL","Attachment","Has this data element been electronically exchanged with external organizations or individuals (including patients)?* (select one)","If yes, with how many outside entities has this been exchanged?* ","Please cite supporting artifacts:*","Supporting Link","Attachment","CHALLENGES                                      Describe any restrictions on the standardization of this data element \n(e.g., proprietary code).*","Describe any restrictions on the use of this data element (e.g., licensing, user fees).*","Describe any privacy and security concerns with the use and exchange of this data element.*","Please provide an estimate of overall burden to implement. Overall estimate of burden to implement, including those not affected by the primary use case(s) (i.e., impact to broader healthcare community for specialty-specific data element submission.)*","Please provide information on other challenges to implementation"]
[null,"Newborn's Delivery Information","Gestational Age","The obstetric estimate of the infant’s gestation in completed weeks based on the birth/delivery attendant’s final estimate of gestation.Includes the method of estimating the gestational age.","No",null,"Monitoring disease and making decisions about public health threats depends on accessible and accurate data. EHRs are a data source with 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.       \n\nThe details of a delivery are crucial for providing the best possible post-natal care to the mother and infant. As well, after delivery, public health needs to capture this data as part of birth certification, fetal death reporting and birth defect reporting. In particular, birth certification forms the basis of the patient census required by a large number of other public health programs including newborn screening, birth defect reporting and immunization registries making it critical that birth certification is as automated, timely and accurate as possible.\n\nThe 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. 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.","Every year there are approximately 3.7 million births in the United States. Consumption of this data is widespread. Every jurisdiction in the country captures birth certification information and immunization administration. Most also capture birth defects and fetal deaths. Healthcare systems which provide care for expectant mothers should be collecting this data.","https://www.cdc.gov/csels/phio/making-ehr-data-more-available.html\nhttps://www.cdc.gov/nchs/nvss/births.htm\nhttps://www.cdc.gov/ncbddd/birthdefects/index.html",{"$nulls":4},"More than 1 but not all","Yes","LOINC codes exist for each of the proposed data elements:\n11884-4 - Gestational age Estimated\n64710-7 - Was your pregnancy a live birth, stillbirth, miscarriage, abortion, or ectopic pregnancy [PhenX]\n9272-6\t- 1 minute Apgar Score\n9274-2\t- 5 minute Apgar Score\n9271-8\t- 10 minute Apgar Score\n\n73766-8 - Place where birth occurred [US Standard Certificate of Live Birth]\n•  Freestanding birthing center (Freestanding birthing center is defined as one which has no direct physical connection with an operative delivery center.)\n•  Home birth\n•  Planned to deliver at home Yes No\n•  Clinic/Doctor’s Office\n•  Other (specify, e.g., taxi cab, train, plane, etc.)","https://loinc.org/\nhttps://phinvads.cdc.gov/vads/SearchHome.action","Yes","Vital Records Common Profiles Library FHIR IG - http://build.fhir.org/ig/HL7/fhir-vr-common-ig/branches/master/index.html\nVital Records Birth and Fetal Death Reporting - https://build.fhir.org/ig/HL7/fhir-bfdr/index.html\nHL7 Version 2.6 Implementation Guide: Vital Records Birth and Fetal Death Reporting, Release 1 STU Release 2 - US Realm https://www.hl7.org/implement/standards/product_brief.cfm?product_id=320\n\nHL7 CDA® R2 Implementation Guide: Birth and Fetal Death Reporting, Release 1, STU Release 2 - US Realm -https://www.hl7.org/implement/standards/product_brief.cfm?product_id=387\n\nIHE Quality, Research and Public Health Technical Framework Supplement – Birth and Fetal Death Reporting-Enhanced (BFDR-E) Revision 3.1 - https://www.ihe.net/uploadedFiles/Documents/QRPH/IHE_QRPH_Suppl_BFDR-E.pdf\n\nBirth Defect Reporting FHIR IG - https://build.fhir.org/ig/HL7/fhir-birthdefectsreporting-ig/index.html\n\nHL7 CDA® R2 Implementation Guide: Ambulatory and Hospital Healthcare Provider Reporting to Birth Defect Registries Release 1 , STU 2 -US Realm - https://www.hl7.org/implement/standards/product_brief.cfm?product_id=428\n","In limited use in production environments","This data is exchanged routinely as part of birth certification, fetal death reporting and birth defect reporting, however these workflows typically are executed on paper or via flat files rather than through electronic interoperability.\nEPIC FHIR APIs for patient, vitals, obstetric details (DSTU2, DSTU3, R4)\nIn production use:\nEPIC stork module (obstetrics) for birth reporting","Facility worksheet information:\nhttps://www.cdc.gov/nchs/data/dvs/facility-worksheet-2016-508.pdf\nhttps://www.cdc.gov/nchs/data/dvs/fetal-death-mother-worksheet-english-2019-508.pdf\nEPIC stork module (obstetrics) for birth reporting: https://www.epic.com/software#PatientEngagement\nEPIC FHIR APIs for patient, vitals, obstetric details:\nhttps://fhir.epic.com/Specifications?api=932\nhttps://fhir.epic.com/Specifications?api=968\nhttps://fhir.epic.com/Specifications?api=966\n",null,"Yes","5 or more","IHE Connectathon integration profiles for BFDR-E (2013 - 2020)\n\nHL7 FHIR Connectathon results (Sept 2020): birth and fetal death reporting results testing between electronic birth registration system vendors (FHIR)\n\nNACCHO 360X Interoperability Demonstrations for Birth and Fetal Death reporting 2020 between NextGen and two state electronic birth registrations system vendors using FHIR.\n\nHIMSS Interoperability showcase (2018 – 2019)","Found in 'New Search', filter by 'Select an integration profile = Birth and Fetal Death Reporting-Enhanced'  https://connectathon-results.ihe.net/view_result.php?rows=company&columns=actor&title=integration_profile\n\nhttps://confluence.hl7.org/display/FHIR/2020-09+Public+Health+Track\nhttps://www.interoperabilityshowcase.org/",null,"None ","None","No concerns over and above the typically privacy and security considerations associated with any health related data.","These data elements are straightforward in nature and should not present a large burden to implement provided the EHR system is capturing the data as part of caring for the woman.","When using FHIR there may be associated costs with 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.  "]
[null,"Newborn's Delivery Information","Place of Birth","An indication of the type of place or situation where birth or delivery occurred","No"]

{"sheet":"Patient Demographics","index":9,"n_rows":11,"n_cols":33,"rows_kept":11,"merged":[[1,6,10,6],[1,7,10,7],[1,8,10,8],[1,9,10,9],[1,10,10,10],[1,11,10,11],[1,12,10,12],[1,13,10,13],[1,14,10,14],[1,15,10,15],[1,16,10,16],[1,17,10,17],[1,18,10,18],[1,19,10,19],[1,20,10,20],[1,21,10,21],[1,22,10,22],[1,23,10,23],[1,24,10,24],[1,25,10,25],[1,26,10,26],[1,27,10,27],[1,28,10,28],[1,29,10,29],[1,30,10,30],[1,31,10,31],[1,32,10,32]]}
[null,"DATA CLASS       Data Class Name","DATA ELEMENT  (1…m Data Element(s) per Data Class)                         Data Element Name","Data Element Description","Similar or related D E's in USCDI","If Yes, why DE considered separately?","USE CASE                                                                                                                               Describe the main use cases to support adoption of the DE into USCDI","Estimate # of stakeholders who would capture, access, use or exchange this DE or DC*","Link to use case project page","Please describe the additional use case:*","FOR ADD USE CASE - Estimate # of stakeholders who would capture, access, use or exchange this DE or DC*","FOR ADD USE CASE -Link URL ","Attachment describing this (unclear if main or ADD Use Case(s)) use case","Does this data element support the following aims in healthcare?* (Check all that Apply)","MATURITY                                    Does a vocabulary, terminology, content, or structural standard exist for this data element? (e.g., SNOMED CT, LOINC, RxNorm) * (select one)","If yes, please cite the applicable standard*","If yes, link URL","Are there additional technical specifications such as an implementation guide (IG) or profile using this data element? (e.g., HL7® FHIR® US Core Implementation Guide v3.1.0 based on FHIR R4)  ","If yes, please cite the relevant technical specification(s)*","Which of the following best describes the use of this data element?* (select one)","Please cite supporting artifacts*","Link URL","Attachment","Has this data element been electronically exchanged with external organizations or individuals (including patients)?* (select one)","If yes, with how many outside entities has this been exchanged?* ","Please cite supporting artifacts:*","Supporting Link","Attachment","CHALLENGES                                      Describe any restrictions on the standardization of this data element \n(e.g., proprietary code).*","Describe any restrictions on the use of this data element (e.g., licensing, user fees).*","Describe any privacy and security concerns with the use and exchange of this data element.*","Please provide an estimate of overall burden to implement. Overall estimate of burden to implement, including those not affected by the primary use case(s) (i.e., impact to broader healthcare community for specialty-specific data element submission.)*","Please provide information on other challenges to implementation"]
[null,"Patient Demographics","Patient Medical Record Number","The medical record number used by the facility to identify the patient. ","No",null,"Monitoring disease and making decisions about public health threats depends on accessible and accurate data. EHRs are a data source with 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.                                                                                                                                                                                                                                                                                                  \n\nPatient 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, 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.  \n\nThe 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. 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.","All 50 states participate in one or more of the public health surveillance use cases that exchange this data element.  \n\nAll 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.\n\nApproximately 420,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.                                            \nThere 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. \n\nAdditionally, public health reporting use cases are part of the 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.","https://www.cdc.gov/csels/phio/making-ehr-data-more-available.html\n\nhttps://www.cdc.gov/cancer/npcr/\n\nhttps://www.cdc.gov/hepatitis/hcv/index.htm\n\nhttps://www.cdc.gov/nchs/dhcs/nhcs_registry_landing.htm\n\nhttps://www.cdc.gov/ecr/index.html\n\nhttps://pcornet.org/\n\nhttps://www.cdc.gov/nchs/nvss/deaths.htm\n\nhttps://www.cdc.gov/nchs/nvss/births.htm\n\n","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",{"$nulls":3},"More than 1 but not all","Yes","Social Security Administration\n\nMedicare Beneficiary Identifiers (MBIs)\n\n","https://www.ssa.gov/history/ssn/geocard.html\n\nhttps://www.cms.gov/Medicare/New-Medicare-Card\n\n","Yes","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)\n\nHL7 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) (Confirm version with Brian)\n\nC-CDA (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) \n\nHL7 FHIR® US Core Implementation Guide STU3 Release 3.1.1 (https://www.hl7.org/fhir/us/core/index.html)\n\nHL7 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)\n\nHL7 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)\n\nIHE Quality, Research and Public Health Birth and Fetal Death Reporting-Enhanced\n(BFDR-E) (https://www.ihe.net/uploadedFiles/Documents/QRPH/IHE_QRPH_Suppl_BFDR-E.pdf)","In limited use in production environments","eCase Reporting with The Council of State and Territorial Epidemiologists (CSTE) and The Association of Public Health Laboratories (APHL)\n\nNational 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.\n\nEPIC stork module (obstetrics) for birth reporting.\n\nIHE integration profiles for BFDR (CDA)\n\nEPIC FHIR patient, vitals, obstetric details (DSTU2, DSTU3, R4)\n\nCerner FHIR patient resource (DSTU2, R4)\n\nEvident FHIR patient resource (DSTU2)\n\nAllscripts FHIR patient resource (DSTU2)","eCase Reporting: https://ecr.aimsplatform.org/about-us#:~:text=A%20US%20federal%20agency%20under,the%20United%20States%20and%20internationally.\n\nhttps://www.cdc.gov/nchs/dhcs/nhcs_registry_home_page.htm\n\nEPIC stork module (obstetrics) for birth reporting: https://www.epic.com/software#PatientEngagement\n\nhttps://www.ihe.net/uploadedFiles/Documents/QRPH/IHE_QRPH_Suppl_BFDR-E.pdf\n\nhttps://fhir.epic.com/Specifications?api=932, https://fhir.epic.com/Specifications?api=968, https://fhir.epic.com/Specifications?api=966\n\nhttp://fhir.cerner.com/millennium/r4/individuals/patient/#retrieve-by-id\n\nhttps://api.evident.com/dstu2/patient\n\nhttps://developer.allscripts.com/FHIR?PageTitle=Resources",null,"Yes","5 or more","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. \n\nHL7 FHIR Connectathon results (Sept 2020): MedMorph/eCR, birth and fetal death reporting, Integrating cancer reporting\n\nNACCHO 360X Interoperability Demonstrations for Cancer, eCR, Birth and Fetal Death and Death reporting 2020 (CDA and FHIR)\n","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\n\nhttps://connectathon-results.ihe.net/view_result.php?rows=company&columns=actor&title=integration_profile\n\nhttps://confluence.hl7.org/display/FHIR/2020-09+Public+Health+Track\n\n",null,"None","None","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.","For those use cases not currently in production level or who have not tested with vendors may require additional development hours or resources.","When using FHIR there may be associated costs with 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.  "]
[null,"Patient Demographics","Patient Medicare Number","The Medicare Beneficiary Identifier (MBI) number is a randomly generated identifier that will not include a SSN or any personal identifiable information.","No"]
[null,"Patient Demographics","Patient Social Security Number","Records patient’s social security number. The number is entered without dashes and without any letter suffix. This is not always identical to the Medicare claim number. ","No"]
[null,"Patient Demographics","Patient Gender Identity","The gender the patient identifies with. The Patient's gender identity is used as guidance (e.g. for staff) about how to interact with the patient.","No"]
[null,"Patient Demographics","Patient Marital Status","Patient marital status at time of event (Diagnosis, Encounter)","No"]
[null,"Patient Demographics","Patient Address Use Period","This is the address start and end date.  The time period is important in determining current address versus address at diagnosis. ","Yes","Current and previous address are captured in USCDI. However, there is no time period associated with a patient's address. Capturing a time period of when a patient lived at specific address locations supports public health reporting when assessing time of exposure within specific residences.  "]
[null,"Patient Demographics","Patient Vital Status","Patient vital status of alive/dead","No"]
[null,"Patient Demographics","Patient Pregnancy Status Observation ","Patient pregnancy status. Is patient pregnant, yes/no","No"]
[null,"Patient Demographics","Patient birth place (City, Town, Or Location Of Delivery)","The state or location in which the patient was born. The City, Town, Or Location of delivery","No"]
[null,"Patient Demographics","Patient Country of Birth","The country in which the patient was born.","No"]

{"sheet":"Patient Work","index":10,"n_rows":6,"n_cols":33,"rows_kept":6,"merged":[[1,6,5,6],[1,7,5,7],[1,8,5,8],[1,9,5,9],[1,10,5,10],[1,11,5,11],[1,12,5,12],[1,13,5,13],[1,14,5,14],[1,15,5,15],[1,16,5,16],[1,17,5,17],[1,18,5,18],[1,19,5,19],[1,20,5,20],[1,21,5,21],[1,22,5,22],[1,23,5,23],[1,24,5,24],[1,25,5,25],[1,26,5,26],[1,27,5,27],[1,28,5,28],[1,29,5,29],[1,30,5,30],[1,31,5,31],[1,32,5,32]]}
[null,"DATA CLASS       Data Class Name","DATA ELEMENT  (1…m Data Element(s) per Data Class)                         Data Element Name","Data Element Description","Similar or related D E's in USCDI","If Yes, why DE considered separately?","USE CASE                                                                                                                               Describe the main use cases to support adoption of the DE into USCDI","Estimate # of stakeholders who would capture, access, use or exchange this DE or DC*","Link to use case project page","Please describe the additional use case:*","FOR ADD USE CASE - Estimate # of stakeholders who would capture, access, use or exchange this DE or DC*","FOR ADD USE CASE -Link URL ","Attachment describing this (unclear if main or ADD Use Case(s)) use case","Does this data element support the following aims in healthcare?* (Check all that Apply)","MATURITY                                    Does a vocabulary, terminology, content, or structural standard exist for this data element? (e.g., SNOMED CT, LOINC, RxNorm) * (select one)","If yes, please cite the applicable standard*","If yes, link URL","Are there additional technical specifications such as an implementation guide (IG) or profile using this data element? (e.g., HL7® FHIR® US Core Implementation Guide v3.1.0 based on FHIR R4)  ","If yes, please cite the relevant technical specification(s)*","Which of the following best describes the use of this data element?* (select one)","Please cite supporting artifacts*","Link URL","Attachment","Has this data element been electronically exchanged with external organizations or individuals (including patients)?* (select one)","If yes, with how many outside entities has this been exchanged?* ","Please cite supporting artifacts:*","Supporting Link","Attachment","CHALLENGES                                      Describe any restrictions on the standardization of this data element \n(e.g., proprietary code).*","Describe any restrictions on the use of this data element (e.g., licensing, user fees).*","Describe any privacy and security concerns with the use and exchange of this data element.*","Please provide an estimate of overall burden to implement. Overall estimate of burden to implement, including those not affected by the primary use case(s) (i.e., impact to broader healthcare community for specialty-specific data element submission.)*","Please provide information on other challenges to implementation"]
[null,"Patient Work (Social History)  - Supporting NIOSH submission","Usual occupation (code; with start date formatted as MM/DD/YYYY or MM/YYYY)","Defined by NIOSH as \"A self-reported, coded term and start date for the  type of work (paid or unpaid) done by a person for the longest amount of time during his or her life, regardless of the person's current occupation and regardless of whether or not the person performed this type of work for a continuous time. Coupled with Usual Industry to characterize the work done for the longest time by a person.\"","No",null,"\n\nMonitoring disease and making decisions about public health threats depends on accessible and accurate data. EHRs are a data source with 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.\n\nThe patient work elements usual occupation and industry are used to help assess occupational and industry exposures related to outcomes within the public health use case(s). These use cases specifically include Electronic Initial Case Reporting (eICR), Cancer Reporting, Message Mapping Guides (MMGs) and the exchange between state electronic death registration systems and the National Center for Health Statistics (NCHS) for death reporting.  Usual Occupation, Usual Industry, and Usual Work Duration can be important to understanding a patient's health, especially in the absence of information about all of the person's past jobs. Together these data can indicate the extent of possible long-term exposure to occupational hazards. These data could support recognition of new and known work-related conditions that develop slowly over time or become evident after the person is no longer performing that type of work, e.g., some respiratory conditions, cancers, and musculoskeletal disorders. \n\nRelated to current work, structured information about a patient’s current work would support multiple data sharing transactions:\n- Transitions of care referrals (e.g., to occupational medicine), sharing patient summaries (e.g., to reduce burden of re-entering the data).\n- Clinical decision support and population health, such as (1) supporting work-related vaccinations, (2) facilitating recognition of known work-related conditions, (3) identifying at risk populations and establishing screening programs (e.g., house painter screening for blood lead and distribution of educational materials).\n- Electronic case reporting to infectious disease programs as well as occupational-health programs, to support outbreak investigations, interventions to prevent further illness or injury, and prioritization of other public health activities.\nIn addition, patient-centered medical homes are required to record occupation and obstetricians are required to ask a pregnant woman’s current job at first visit. However, the data are likely to be collected as text and therefore less amenable to use by tools that assist with clinical decisions and population health. \n\nThe 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. 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.","All 50 states participate in one or more of the public health surveillance use cases that exchange this data element. \n\nAll 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 in the United States.\n\nAdditionally, public health reporting use cases are part of the 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.","https://www.cdc.gov/niosh/topics/ehr/ \n\nhttps://www.cdc.gov/csels/phio/making-ehr-data-more-available.html\n\nhttps://www.cdc.gov/cancer/npcr/\n\n\nhttps://www.cdc.gov/nchs/dhcs/nhcs_registry_landing.htm\n\nhttps://www.cdc.gov/ecr/index.html\n\nhttps://www.cdc.gov/nchs/nvss/deaths.htm\n\n","Usual Work also supports Critical Congenital Heart Defects Report requirements.\nThese data could contribute to patient matching algorithms.\n\nInclusion of patient work in the IHE Exchange of Personal Health Record Profile facilitates data collection and could decrease the burden to share these data with care providers.\nAnalytics using these data could facilitate recognition of new or less-easily recognized work-related conditions. For example, fixed obstructive lung disease caused by inhalation of butter flavoring chemicals was first recognized in 2000 among former workers of a microwave popcorn manufacturing plant, but a review subsequently found that the relationship between occupational exposure and disease could be found back to 1985.\nThese data could contribute to patient matching algorithms.","More than half of US adults are workers, suggesting that most primary care providers would potentially benefit from the capture, access, use, and exchange of these data.\n\nIn the US, more than half of the adults are workers, suggesting that most primary care providers would potentially benefit from the capture, access, use, and exchange of these data.\nMany specialty providers would also benefit from these data, e.g., recognizing and proving treatment for work-related conditions.","https://www.cdc.gov/niosh/topics/ehr/",null,"All of above","Yes","ODH code set\n\nCancer reporting - Census Ind Code 2010 CDC\n\nCancer reporting - Census Occ Code 2010 CDC\n\nMMG:\nCurrent Occupation (text field)\nCurrent Occupation Standardized (Occupation CDC Census 2010 )\n\nCurrent Industry (text field)\nCurrent Industry Standardized (Industry CDC Census 2010)\n\n\nMarovich S, Luensman GB, Wallace B, Storey E. Opportunities at the Intersection of Work and Health: Developing the Occupational Data for Health Information Model. J Am Med Inform Assoc. 2020 Jul 1;27(7): 1072–1083, https://doi.org/10.1093/jamia/ocaa070. \n\n","Code set:  https://phinvads.cdc.gov/vads/ViewCodeSystem.action?id=2.16.840.1.114222.4.5.327\nValue set listing: https://phinvads.cdc.gov/vads/SearchValueSets_search.action?searchOptions.searchText=ODH\n\nCode for the patient's usual industry, using U.S. Census Bureau codes and NIOSH non-paid worker codes = 6570\n\nCode for the patient's usual occupation, using U.S. Census Bureau codes and NIOSH non-paid worker codes = 2700\n\nCurrent Occupation (text field)\nCurrent Occupation Standardized (Occupation CDC Census 2010 - https://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.114222.4.11.7186)\n\nCurrent Industry (text field)\nCurrent Industry Standardized (Industry CDC Census 2010: https://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.114222.4.11.7187)","Yes","IHE Patient Care Coordination (PCC) Technical Framework Supplement: CDA Content Modules, Revision 2.6 – Trial Implementation. 2020 Jun 17. https://www.ihe.net/resources/technical_frameworks/#pcc.\nHL7 CDA® R2 Implementation Guide: Consolidated CDA Templates for Clinical Notes; Occupational Data for Health, Release 1 – US Realm; HL7 Standard for Trial Use 2020 Jan. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=522. \nHL7 Version 2.9 Messaging Standard – An Application Protocol for Electronic Data Exchange in Healthcare Environments, Normative. 2019 Dec. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=516. \nHL7 FHIR Release 4.0.1 Profile: Occupational Data for Health (ODH), Release 1.0 (Standard for Trial Use). 2020 Jan 8. http://hl7.org/fhir/us/odh/STU1/.\nHL7 CDA R2 Implementation Guide: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1 – US Realm; HL7 Draft Standard for Trial Use. 2015 Apr. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=398. \nHL7 CDA R2 Implementation Guide: Vital Records Death Reporting, Release 1, STU 2.1 – US Realm; HL7 Standard for Trial Use. 2019 Jan. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=386.\nIHE Patient Care Coordination (PCC) Technical Framework Supplement: Query for Existing Data for Mobile (QEDm), Revision 2.2 – Trial Implementation. 2020 Jul 17. https://www.ihe.net/resources/technical_frameworks/#pcc.\nIHE Patient Care Coordination (PCC) Technical Framework Supplement: International Patient Summary (IPS), Revision 1.1 – Trial Implementation. 2020 Jun 17. https://www.ihe.net/resources/technical_frameworks/#pcc. \nIHE Patient Care Coordination (PCC) Technical Framework Supplement to Volume 1, CDA Occupational Data Options, Revision 1.1 – Trial Implementation. 26 Aug 2020. https://www.ihe.net/resources/technical_frameworks/#pcc. This adds ODH to three profiles in the PCC Technical Framework: Cross-Enterprise Sharing of Medical Summaries (XDS-MS), Exchange of Personal Health Record (XPHR), Emergency Department Referral (EDR).\nHL7 CDA R2 Implementation Guide: Public Health Case Report – the Electronic Initial Case Report (eICR), Release 1.1 – US Realm; HL7 Standard for Trial Use and Release 1, STU Release 2.0. 2020 Feb. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=436.\nHL7 FHIR® Release 4.0.1 Implementation Guide: Electronic Case Reporting (eCR) – US Realm. Version 1.0.0 (Standard for Trial Use). 2020 Jan 29. http://hl7.org/fhir/us/ecr/STU1/.\nIHE Quality, Research and Public Health Technical Framework Supplement: Healthy Weight (HW), Revision 2.3 – Trial Implementation 2020 Feb 14. https://www.ihe.net/resources/technical_frameworks/#qrph.\nHL7 Public Health Work Group, sponsor. HL7 Version 2.6 Implementation Guide: Critical Congenital Heart Defects (CCHD), Release 1, Normative. 2020 Aug. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=366.\nHL7® EHRS-FM Release 2 Functional Profile: Work and Health, Release 1 - U.S. Realm, HL7 Informative Document 2019 Apr. http://www.hl7.org/implement/standards/product_brief.cfm?product_id=498.","In limited use in production environments","Usual Occupation and Usual Industry are required for reporting to state cancer registries.\n\neCase Reporting with The Council of State and Territorial Epidemiologists (CSTE) and The Association of Public Health Laboratories (APHL) - C- CDA Currently implemented in 5,400 + reporting sites nationally\n","Cancer Reporting: http://datadictionary.naaccr.org/default.aspx?c=8&Version=21\n\neCase Reporting: https://ecr.aimsplatform.org/about-us#:~:text=A%20US%20federal%20agency%20under,the%20United%20States%20and%20internationally.\n\n",null,"Yes","5 or more","\nIHE Connectathons 2017-2010 (CDA; as part of Healthy Weight Profile)\n\nHIMSS Interoperability Showcase 2016-19 (CDA)\n\nPublic Health Informatics Conference Interoperability Showcase 2016, 2018 (CDA)\n\nNACCHO 360X Interoperability Demonstrations, 2020 (CDA and FHIR)\n\nIHE Connectathon integration profiles Cancer reporting (2010 - 2020).\n\nHL7 FHIR Connectathon results for (2) use cases: MedMorph/eCR, death reporting (electronic death registration system to NCHS only)","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\n\nhttps://confluence.hl7.org/display/FHIR/2020-09+Public+Health+Track\n",null,"None","None","These data are intended to be a part of the medical record and protected as such.","Approximately 300 hours to implement as described in the HL7 EHR-S Work and Health Functional Profile and additional guidance for collection of occupation and industry.","The industry and occupation value sets are large, in order to provide recognizable terms. However, keyword text searches can be used to facilitate selection and NIOSH will provide additional guidance."]
[null,"Patient Work (Social History)  - Supporting NIOSH submission","Usual Occupation Duration (integer)","Defined by NIOSH as \"The self-reported total of all periods of time a person has spent in their Usual Occupation as of the date recorded, not including intermittent period(s) when the person was not working in that occupation.\"","No"]
[null,"Patient Work (Social History)  - Supporting NIOSH submission","Usual Industry (code)","Defined by NIOSH as \"A self-reported term that identifies the kind of business, i.e., primary business activity, in which a person has worked for the longest time while in their usual occupation. Coupled with Usual Occupation to characterize the work done for the longest time by a person.\"","No"]
[null,"Patient Work (Social History)  - Supporting NIOSH submission","Current occupation (code; with start date formatted as MM/DD/YYYY or MM/YYYY)","As defined by NIOSH \"A self-reported, coded term and start date that identifies the type of work done by a person in a current work situation or position (i.e., a job; also some voluntary work, such as volunteer firefighter). The self-reported term for a set of activities or tasks that a person is currently paid to perform or, if unpaid or voluntary, the person’s contribution to a household/family business/community. Paired with current industry to characterize a job.\"","No"]
[null,"Patient Work (Social History)  - Supporting NIOSH submission","Current industry (code)","As defined  by NIOSH \"A self-reported term that identifies the kind of business, i.e., primary business activity, conducted by the company, organization, or individual that provides compensation (either direct or indirect) for a current job or that currently assigns work to a volunteer. Characterizes a job/voluntary work when paired with current occupation. For a military position, this is the self-reported branch of service.\"","No"]

{"sheet":"Problems","index":11,"n_rows":8,"n_cols":33,"rows_kept":8,"merged":[[1,6,5,6],[1,7,5,7],[1,8,5,8],[1,9,5,9],[1,10,5,10],[1,11,5,11],[1,12,5,12],[1,13,5,13],[1,14,5,14],[1,15,5,15],[1,16,5,16],[1,17,5,17],[1,18,5,18],[1,19,5,19],[1,20,5,20],[1,21,5,21],[1,22,5,22],[1,23,5,23],[1,24,5,24],[1,25,5,25],[1,26,5,26],[1,27,5,27],[1,28,5,28],[1,29,5,29],[1,30,5,30],[1,31,5,31],[1,32,5,32]]}
[null,"DATA CLASS       Data Class Name","DATA ELEMENT  (1…m Data Element(s) per Data Class)                         Data Element Name","Data Element Description","Similar or related DE's in USCDI","If Yes, why DE considered separately?","USE CASE                                                                                                                               Describe the main use cases to support adoption of the DE into USCDI","Estimate # of stakeholders who would capture, access, use or exchange this DE or DC*","Link to use case project page","Please describe the additional use case:*","FOR ADD USE CASE - Estimate # of stakeholders who would capture, access, use or exchange this DE or DC*","FOR ADD USE CASE -Link URL ","Attachment describing this (unclear if main or ADD Use Case(s)) use case","Does this data element support the following aims in healthcare?* (Check all that Apply)","MATURITY                                    Does a vocabulary, terminology, content, or structural standard exist for this data element? (e.g., SNOMED CT, LOINC, RxNorm) * (select one)","If yes, please cite the applicable standard*","If yes, link URL","Are there additional technical specifications such as an implementation guide (IG) or profile using this data element? (e.g., HL7® FHIR® US Core Implementation Guide v3.1.0 based on FHIR R4)  ","If yes, please cite the relevant technical specification(s)*","Which of the following best describes the use of this data element?* (select one)","Please cite supporting artifacts*","Link URL","Attachment","Has this data element been electronically exchanged with external organizations or individuals (including patients)?* (select one)","If yes, with how many outside entities has this been exchanged?* ","Please cite supporting artifacts:*","Supporting Link","Attachment","CHALLENGES                                      Describe any restrictions on the standardization of this data element \n(e.g., proprietary code).*","Describe any restrictions on the use of this data element (e.g., licensing, user fees).*","Describe any privacy and security concerns with the use and exchange of this data element.*","Please provide an estimate of overall burden to implement. Overall estimate of burden to implement, including those not affected by the primary use case(s) (i.e., impact to broader healthcare community for specialty-specific data element submission.)*","Please provide information on other challenges to implementation"]
[null,"Problems (RENAME TO CONDITION)","Condition Onset Date","Estimated or actual date or date-time the condition began.","No",null,"Actively monitoring diseases, making decisions about public health threats, identifying trends in healthcare services utilization and other public health matters depend on accessible and accurate data. EHRs are a data source that can 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 more rapid disease detection, tracking, and treatment and innovation in healthcare delivery. \n\nCondition information, including the condition's onset and abatement dates, condition/diagnosis code, and the condition/diagnosis recorded date are important to multiple public health reporting and research use cases to track and analyze information about treatment for various health conditions.\n\nThe Making EHR Data More Available for Research and Public Health (MedMorph) project's goal is to create a reliable, scalable, and interoperable method to get electronic health record data for multiple public health and research scenarios (use cases). 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 and Birth Defect Reporting use cases that support the adoption of these data elements. These specific use cases are described in more depth on their respective web pages. ","All 50 states participate in one or more of the public health use cases that exchange these data element. Up to 14 territorial or city jurisdictions also participate in one of these public health use cases and use these data elements. \n\nAll hospitals and physicians who diagnose or treat cancer are required to provide cancer related problem information to state cancer registries. \n\nApproximately 420,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.                                            \nThere 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. The vast majority of these exchanges include full sets of medication data, including the data elements requested for USCDI consideration here","MedMorph Project Page: https://www.cdc.gov/csels/phio/making-ehr-data-more-available.html\n\nCancer Reporting: https://www.cdc.gov/cancer/npcr/\n\nHealthcare Surveys: https://www.cdc.gov/nchs/dhcs/nhcs_registry_landing.htm \n\nHepatitis C Reporting: https://www.cdc.gov/hepatitis/pdfs/HepatitisCaseRprtForm.pdf\n\neICR: https://www.cdc.gov/ecr/index.html\n\nMCC eCare Plan: https://confluence.hl7.org/display/PC/Multiple+Chronic+Conditions+%28MCC%29+eCare+Plan\n\nMessage Mapping Guide for COVID 19: https://wwwn.cdc.gov/nndss/case-notification/message-mapping-guides.html\n\nPCORnet: https://pcornet.org/\n\nBirth Defect Reporting: https://www.cdc.gov/nchs/nvss/births.htm","A foundational goal of MedMorph is generalizability beyond the 10 use cases that are actively informing the MedMorph project, in order 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 these data elements. ",{"$nulls":3},"Improving the health of populations ","Yes","Condition Onset Date, Condition Abatement Date: FHIR dateTime|Age|Period|Range|string datatypes\n\nCondition/Diagnosis Recorded Date: FHIR dateTime datatype\n\nCondition/Diagnosis Code:  SNOMED CT","Condition Onset Date, Condition Abatement Date: http://hl7.org/fhir/condition-definitions.html#Condition.onset_x_\n\nCondition/Diagnosis Recorded Date: http://hl7.org/fhir/datatypes.html#dateTime\n\nCondition/Diagnosis Code: http://snomed.info/sct where concept is-a 404684003 (Clinical finding)","Yes","HL7 FHIR US Core Implementation Guide v3.1.1: https://www.hl7.org/fhir/us/core/index.html\n\nHL7 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\n\nHL7 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\n\nC-CDA (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\n\nHL7 FHIR® Implementation Guide: Electronic Case Reporting (eCR) - US Realm: http://hl7.org/fhir/us/ecr/STU1/\n\nHL7 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\n\nHL7 CDA® R2 Implementation Guide: Ambulatory and Hospital Healthcare Provider Reporting to Birth Defect Registries Release 1 , STU 2 -US Realm: https://www.hl7.org/implement/standards/product_brief.cfm?product_id=428\n\nHL7 FHIR® Implementation Guide: Birth Defect Reporting Implementation Guide 0.1.0: https://build.fhir.org/ig/HL7/fhir-birthdefectsreporting-ig/index.html\n\nHL7 FHIR® Implementation Guide: Common Data Models Harmonization FHIR Implementation Guide (Release 0.1.0): http://hl7.org/fhir/us/cdmh/2019May/","Extensively used in production environments","Widely available in EHR systems.\n\nPart of Core EHR Certification since at least 2014 (is this correct? Need confirmation) \nSpecified in Meaningful Use/Promoting Interoperability since Stage 1 (is this correct? Need confirmation)\nPart of EHR Certification for Transmission to Cancer Registries (2015 and 2014 Editions)\n\nThese data elements exist in FHIR with a FHIR Maturity level of 3 for the Condition Resource.\n\nSNOMED CT and ICD-10-CM are included in the ISA with an adoption level of 4 in production implementations. \n\nIHE Connectathons 2010-2020 (CDA; as part of Cancer Reporting IGs)\nHIMSS Interoperability Showcase 2010-19 (CDA; as part of Cancer Reporting IGs)\nPublic Health Informatics Conference Interoperability Showcase 2014, 2016, 2018 (CDA; as part of Cancer Reporting IGs)\nNACCHO 360X Interoperability Demonstrations, 2020 (CDA; as part of Cancer Reporting IGs)\n\nIHE Connectathons 2019-2020 (CDA; as part of National Health Care Surveys IGs)               ","https://fhir.epic.com/Specifications\n\nhttps://developer.allscripts.com/FHIR?PageTitle=Resources\n\nhttp://hl7.org/fhir/condition.html\n\nhttps://www.healthit.gov/isa/representing-patient-medical-encounter-diagnosis\n\nhttps://www.healthit.gov/test-method/transmission-cancer-registries#test_procedure\n\nhttps://www.healthit.gov/sites/default/files/2014_test_methods/2014_edition_test_methods_archived.zip",null,"Yes","5 or more. This data element has been tested at scale between multiple different production environments to support the majority of anticipated stakeholders. ","IHE Connectathons 2010-2020 (CDA; as part of Cancer Reporting IGs)\nHIMSS Interoperability Showcase 2010-19 (CDA; as part of Cancer Reporting IGs)\nPublic Health Informatics Conference Interoperability Showcase 2014, 2016, 2018 (CDA; as part of Cancer Reporting IGs)\nNACCHO 360X Interoperability Demonstrations, 2020 (CDA; as part of Cancer Reporting IGs)\n\nIHE Connectathons 2019-2020 (CDA; as part of National Health Care Surveys IGs)                                                                                     ONC Interoperability Standards Advisory - Sending Health Care Survey Information to Public Health Agencies - see:                                      https://www.healthit.gov/isa/sending-health-care-survey-information-public-health-agencies                                                ","https://chpl.healthit.gov/#/search: 170.315 (f)(4): Transmission to Cancer Registries\nRetired | 170.314 (f)(5): Optional - ambulatory setting only - cancer case information\nRetired | 170.314 (f)(6): Optional - ambulatory setting only - transmission to cancer registries)",null,"None","None","None","Low.\n\nAll providers need to capture problems/conditions information as a basic component of patient care. \n\nSeveral existing IGs, as listed, require exchange of this data element. The Promoting Interoperability Programs Objective 8 - Public Health and Clinical Data Registry Reporting, Measures 1: Immunization Registry Reporting, 2: Syndromic Surveillance Reporting, 3 -: Electronic Case Reporting and 4: Public Health Registry Reporting all require these data elements.\n \nThis information is routinely communicated in HL7 CDA Documents and some FHIR API transactions.","None"]
[null,"Problems (RENAME TO CONDITION)","Condition Abatement Date","The date or estimated date that the condition resolved or went into remission. ","No"]
[null,"Problems (RENAME TO CONDITION)","Condition/Diagnosis Code","Identification of the condition, problem or diagnosis.","Yes","The current element of \"Problems\" does not specifically state that this is used to capture the code of the condition or diagnosis. Suggest renaming the current element of \"Problems\" to \"Condition/Diagnosis Code\""]
[null,"Problems (RENAME TO CONDITION)","Date of Diagnosis",null,"No"]
[null,"Problems (RENAME TO CONDITION)","Condition/Diagnosis Recorded Date","The date when this particular condition record was created in the system, which is often a system-generated date.","No"]
[]
[{"$nulls":10},"  "]

{"sheet":"Procedures","index":12,"n_rows":8,"n_cols":33,"rows_kept":8,"merged":[[1,6,2,6],[1,7,2,7],[1,8,2,8],[1,9,2,9],[1,10,2,10],[1,11,2,11],[1,12,2,12],[1,13,2,13],[1,14,2,14],[1,15,2,15],[1,16,2,16],[1,17,2,17],[1,18,2,18],[1,19,2,19],[1,20,2,20],[1,21,2,21],[1,22,2,22],[1,23,2,23],[1,24,2,24],[1,25,2,25],[1,26,2,26],[1,27,2,27],[1,28,2,28],[1,29,2,29],[1,30,2,30],[1,31,2,31],[1,32,2,32]]}
[null,"DATA CLASS       Data Class Name","DATA ELEMENT  (1…m Data Element(s) per Data Class)                         Data Element Name","Data Element Description","Similar or related DE's in USCDI","If Yes, why DE considered separately?","USE CASE                                                                                                                               Describe the main use cases to support adoption of the DE into USCDI","Estimate # of stakeholders who would capture, access, use or exchange this DE or DC*","Link to use case project page","Please describe the additional use case:*","FOR ADD USE CASE - Estimate # of stakeholders who would capture, access, use or exchange this DE or DC*","FOR ADD USE CASE -Link URL ","Attachment describing this (unclear if main or ADD Use Case(s)) use case","Does this data element support the following aims in healthcare?* (Check all that Apply)","MATURITY                                    Does a vocabulary, terminology, content, or structural standard exist for this data element? (e.g., SNOMED CT, LOINC, RxNorm) * (select one)","If yes, please cite the applicable standard*","If yes, link URL","Are there additional technical specifications such as an implementation guide (IG) or profile using this data element? (e.g., HL7® FHIR® US Core Implementation Guide v3.1.0 based on FHIR R4)  ","If yes, please cite the relevant technical specification(s)*","Which of the following best describes the use of this data element?* (select one)","Please cite supporting artifacts*","Link URL","Attachment","Has this data element been electronically exchanged with external organizations or individuals (including patients)?* (select one)","If yes, with how many outside entities has this been exchanged?* ","Please cite supporting artifacts:*","Supporting Link","Attachment","CHALLENGES                                      Describe any restrictions on the standardization of this data element \n(e.g., proprietary code).*","Describe any restrictions on the use of this data element (e.g., licensing, user fees).*","Describe any privacy and security concerns with the use and exchange of this data element.*","Please provide an estimate of overall burden to implement. Overall estimate of burden to implement, including those not affected by the primary use case(s) (i.e., impact to broader healthcare community for specialty-specific data element submission.)*","Please provide information on other challenges to implementation"]
[null,"Procedures","Procedure Code","\t\nThe specific procedure that is performed.","Yes","The current element of Procedures does not specifically state that this is used to capture the code of the procedure performed. Suggest renaming the current element of \"Procedures\" to \"Procedure Code\"","Actively monitoring diseases, making decisions about public health threats, identifying trends in healthcare services utilization and other public health matters depend on accessible and accurate data. EHRs are a data source that can 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 more rapid disease detection, tracking, and treatment and innovation in healthcare delivery. \n\nProcedure information, including the coded identification and the date the procedure was performed, are important to multiple public health reporting and research use cases to track and analyze information about treatment for various health conditions.\n\nThe Making EHR Data More Available for Research and Public Health (MedMorph) project's goal is to create a reliable, scalable, and interoperable method to get electronic health record data for multiple public health and research scenarios (use cases). MedMorph has identified Cancer Reporting, Healthcare Surveys, and Multiple Chronic Conditions (MCC) eCare Plan (for date only) use cases that support the adoption of these data elements. These specific use cases are described in more depth on their respective web pages. ","All 50 states participate in one or more of the public health use cases that exchange these data element. Up to 14 territorial or city jurisdictions also participate in one of these public health use cases and use these data elements. \n\nAll hospitals and physicians who diagnose or treat cancer are required to provide cancer related procedure information to state cancer registries. \n\nApproximately 420,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.                                            \nThere 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. The vast majority of these exchanges include full sets of medication data, including the data elements requested for USCDI consideration here.","MedMorph Project Page: https://www.cdc.gov/csels/phio/making-ehr-data-more-available.html\n\nCancer Reporting: https://www.cdc.gov/cancer/npcr/\n\nHealthcare Surveys: https://www.cdc.gov/nchs/dhcs/nhcs_registry_landing.htm \n\nMCC eCare Plan: https://confluence.hl7.org/display/PC/Multiple+Chronic+Conditions+%28MCC%29+eCare+Plan","A foundational goal of MedMorph is generalizability beyond the 10 use cases that are actively informing the MedMorph project, in order 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 these data elements. ",{"$nulls":3},"Improving the health of populations ","Yes","Procedure Code (same as current USCDIv1):     \nHealth Care Financing Administration Common Procedure Coding System (HCPCS), as maintained and distributed by HHS.\nCurrent Procedural Terminology, Fourth Edition (CPT-4), as maintained and distributed by the American Medical Association, for physician services and other health care services.\nSNOMED International, Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT®) U.S. Edition, September 2019 Release\nOptional:\nInternational Classification of Diseases ICD-10-PCS 2020\nOptional for technology which records dental procedures: Code on Dental Procedures and Nomenclature (CDT), maintained and distributed by the American Dental Association, for dental services.\n\nProcedure Date: HL7 FHIR Datatypes (dateTime|Period|string|Age|Range)","Procedure Code:\nHCPCS: http://www.cms.gov/Medicare/Coding/HCPCSReleaseCodeSets/index.html\nCPT-4: http://www.ama-assn.org/ama/pub/physician-resources/solutions-managing-your-practice/coding-billing-insurance/cpt.page\nSNOMED CT: http://www.nlm.nih.gov/research/umls/Snomed/snomed_main.html\nICD-10-PCS: http://www.cms.gov/Medicare/Coding/ICD10/index.html\nCDT: http://www.ada.org/en/publications/cdt\n\nProcedure Date: http://hl7.org/fhir/datatypes.html#dateTime\nhttp://hl7.org/fhir/datatypes.html#Period\nhttp://hl7.org/fhir/datatypes.html#string\nhttp://hl7.org/fhir/datatypes.html#Age\nhttp://hl7.org/fhir/datatypes.html#Range","Yes","HL7 FHIR US Core Implementation Guide v3.1.1: https://www.hl7.org/fhir/us/core/index.html\n\nHL7 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\n\nHL7 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","Extensively used in production environments","Widely available in EHR systems.\n\nPart of Core EHR Certification since at least 2014 \nSpecified in Meaningful Use/Promoting Interoperability since Stage 1 \nPart of EHR Certification for Transmission to Cancer Registries (2015 and 2014 Editions)\n\nThese data elements exist in FHIR with a FHIR Maturity level of 3 for the Procedure Resource.\n\nSNOMED CT, CPT-4, HCPCS are included in the ISA with an adoption level of 5 in production implementations. ICD-10-PCS and CDT are included in the ISA with an adoption level of 4 in production implementations.\n\nIHE Connectathons 2010-2020 (CDA; as part of Cancer Reporting IGs)\nHIMSS Interoperability Showcase 2010-19 (CDA; as part of Cancer Reporting IGs)\nPublic Health Informatics Conference Interoperability Showcase 2014, 2016, 2018 (CDA; as part of Cancer Reporting IGs)\nNACCHO 360X Interoperability Demonstrations, 2020 (CDA; as part of Cancer Reporting IGs)\n\nIHE Connectathons 2019-2020 (CDA; as part of National Health Care Surveys IGs)     ","https://fhir.epic.com/Specifications\n\nhttps://developer.allscripts.com/FHIR?PageTitle=Resources\n\nhttp://hl7.org/fhir/procedure.html\n\nhttps://www.healthit.gov/isa/representing-medical-procedures-performed\n\nhttps://www.healthit.gov/test-method/transmission-cancer-registries#test_procedure\n\nhttps://www.healthit.gov/sites/default/files/2014_test_methods/2014_edition_test_methods_archived.zip",null,"Yes","5 or more. This data element has been tested at scale between multiple different production environments to support the majority of anticipated stakeholders. ","IHE Connectathons 2010-2020 (CDA; as part of Cancer Reporting IGs)\nHIMSS Interoperability Showcase 2010-19 (CDA; as part of Cancer Reporting IGs)\nPublic Health Informatics Conference Interoperability Showcase 2014, 2016, 2018 (CDA; as part of Cancer Reporting IGs)\nNACCHO 360X Interoperability Demonstrations, 2020 (CDA; as part of Cancer Reporting IGs)\n\nIHE Connectathons 2019-2020 (CDA; as part of National Health Care Surveys IGs)                                                                                     ONC Interoperability Standards Advisory - Sending Health Care Survey Information to Public Health Agencies - see:                                      https://www.healthit.gov/isa/sending-health-care-survey-information-public-health-agencies                                                Need eCR info added\n\nOthers through MU/PI? \nReview/input needed","https://chpl.healthit.gov/#/search: 170.315 (f)(4): Transmission to Cancer Registries\nRetired | 170.314 (f)(5): Optional - ambulatory setting only - cancer case information\nRetired | 170.314 (f)(6): Optional - ambulatory setting only - transmission to cancer registries)",null,"None","None","None","Low.\n\nAll providers need to capture procedure information as a basic component of patient care. \n\nSeveral existing IGs, as listed, require exchange of this data element. The Promoting Interoperability Programs Objective 8 - Public Health and Clinical Data Registry Reporting, Measures 1: Immunization Registry Reporting, 2: Syndromic Surveillance Reporting, 3 -: Electronic Case Reporting and 4: Public Health Registry Reporting all require these data elements.\n \nThis information is routinely communicated in HL7 CDA Documents and some FHIR API transactions.","None"]
[null,"Procedures","Procedure Date","Estimated or actual date, date-time, period, or age when the procedure was performed. Allows a period to support complex procedures that span more than one date, and also allows for the length of the procedure to be captured.","No"]
[]
[]
[]
[]
[{"$nulls":10},"  "]

{"sheet":"Sheet2","index":13,"n_rows":28,"n_cols":8,"rows_kept":28}
[]
["similar?","Yes","No","Unknown",null,null,"Aim?","Improving patient experience of care (quality and/or satisfaction) "]
[{"$nulls":7},"Improving the health of populations "]
[{"$nulls":7},"Reducing the cost of care "]
[{"$nulls":7},"Improving provider experience of care "]
[{"$nulls":7},"All of above"]
[{"$nulls":7},"More than 1 but not all"]
[{"$nulls":7},"None of the above  "]
[]
[]
[]
["Which of the following best describes the use of this data element?* (select one)"]
["Not currently captured or accessed with an organization"]
["In limited use in test environments only"]
["In limited use in production environments"]
["Extensively used in production environments"]
["This data element has been used at scale between multiple different production environments to support the majority of anticipated stakeholders"]
[]
[]
[]
[null,"Yes"]
[null,"No"]
[]
[]
[null,1]
[null,"2-3      "]
[null,4]
[null,"5 or more. This data element has been tested at scale between multiple different production environments to support the majority of anticipated stakeholders. "]