{"text_format":"1","workbook":"xlsx","n_sheets":5,"sheets":["Table of Contents","Data Flow Enhancements","ESSENCE Enhancements","AMC Enhancements","Definitions"],"not_rendered":{"charts":0,"images":0,"macros":0,"external_links":0,"defined_names":3,"comments":0,"pivot_tables":0},"unopened":[],"bounds":{"document_bytes":16777216,"sheet_cells":100000,"rows_first":2000,"rows_last":500,"rows_between":2000,"halvings":0,"cell_chars":16384,"cell_head_chars":4096},"cells_cut":0,"cells_raw":0,"read":"whole","date_system":"1900"}

{"sheet":"Table of Contents","index":0,"n_rows":88,"n_cols":6,"rows_kept":88,"cut":false,"hidden":false,"merged":[[1,1,1,5],[87,1,93,1],[87,2,93,2],[18,1,23,1],[18,2,23,2],[24,1,30,1],[24,2,30,2],[31,1,37,1],[31,2,37,2],[16,3,16,5]]}
[]
[null,"BioSense Platform Enhancements (January 2018)"]
[]
[null,"This workbook contains tabs for the following: "]
[]
[null,"Tab","Name",null,null,"Description"]
[null,null,"Data Flow"]
[null,1,"Data Flow Enhancements",null,null,"Contains information on known data processing/quality issues and plan for resolution"]
[null,null,"ESSENCE"]
[null,2,"ESSENCE Enhancements",null,null,"Contains information on known issues and plan for resolution\nIncludes the enhancement description, status summary, and status update"]
[null,null,"Access and Management Center"]
[null,3,"AMC Enhancements",null,null,"Contains information on known issues and plan for resolution and plans for general improvement to improve user experience "]
[null,null,"Definitions"]
[null,4,"Definitions",null,null,"Defines values in \"Priority,\" \"Status,\" and \"Issue Type\" columns for all tabs\n(Dictates dropdown options for those columns)"]
[]
[]
[null,"Document Version","Date","Version Notes"]
[]
[null,1,"2018-12-17","Initial Version"]
[]
[null,null,null,"Data Flow Enhancements "]
[null,null,null,"- Moved from DataFlowElementRequirements_v33_Draft_1"]
[null,null,null,"- Added Issues 23-32"]
[null,null,null,"- Updated Issues 15 and 16"]
[null,2]
[]
[]
[]
[]
[]
[]
[null,3]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[null,4]

{"sheet":"Data Flow Enhancements","index":1,"n_rows":35,"n_cols":13,"rows_kept":35,"cut":false,"hidden":false,"merged":[[0,0,0,12],[1,0,1,1],[1,2,1,3],[1,4,1,8],[1,9,1,12]]}
["Data Flow Enhancements"]
["Issue #",null,"Status and Priority",null,"Enhancement Summary",null,null,null,null,"Implementation Status"]
["Issue #","JIRA Ticket","Status","Priority","Issue Type","Issue","Resolution","Affected Fields","Notes","NSSP Processing Logic Updated?","ESSENCE Processing Logic Updated?","NSSP Retrospective Archive Data Patched?","Retrospective ESSENCE Data Patched?"]
[1,null,"Complete","High ","Enhancement","C_Patient_Class\n\nInconsistent values in C_Patient_Class ","Update C_Patient_Class processing as follows:\n1) Patient_Class_Code (PV1-2) if it is not null AND valid according to the PHIN standard (D, E, I, V, B, O, P, R)\n2) ELSE use a mapped Patient_Class_Code (PV1-2), if not null AND not valid AND one of the following mapped values: \n    - Emergency: E \n    - Inpatient: I \n    - Observation: V\n    - EMER: E \n    - EMERGENCY: E\n    - INPATIENT: I\n    - HOS: I\n    - OBSERVE: V\n    - Emergency Department: E\n    - Outpatient: O\n    - ICU: I\n    - Obsv: V\n    - OUTPATIENT: O\n    - ER: E\n3) ELSE use C_FacType_Patient_Class\n4) ELSE assign class value based on the inferred patient class associated with the primary entry on the MFT (C_MFT_Patient_Class).  (Requires a look-up to the MFT table for the entry flagged as primary with Site_ID-C_Facility_ID; return the Inferred_Patient_Class value matching that entry).","C_Patient_Class\nC_Patient_Class_Source\nC_Patient_Class (ESSENCE)","The C_Patient_Class updates were applied to retrospective data in ESSENCE; however, C_Patient_Class_source updates were not made.   For ESSENCE data - Values in C_Patient_Class_Source may not align with the source that was actually used to populate C_Patient_Class for records prior to mid-October 2017.  The core PROCESSED data does have the updated C_Patient_Class_Source. \n\nUpdates to C_Patient_Class Calculation were instrumental in the addition of the \"HasBeen\" E, I, and O fields in the ESSENCE Application.\n\nTechnical Committee Comment 11/27/2018: Technical Committee agrees that patient class source does not need to be updated in ESSENCE. It was also noted that values for D/B/P/R should be included in Resolution (Column G) list for #2.","Yes \n09/06/17","N/A","Yes\n09/08/17","Yes"]
[{"$f":"A4+1","v":2},"BA-3670, \nBA-3671, \nBA-3914, \nBA-3671, \nBA-3674, \nBA-3913, \nBA-3675","Complete","High ","Enhancement","Semicolon Wrap","In order to facilitate ESSENCE querying, Admit_Reason_Code, Chief_Complaint_Code, Diagnosis_Code, and Procedure_Code will now be wrapped in semicolons.\n\nUpdated processing for new incoming data is as follows:\n   a. If value is non-NULL, start and end the string with a semicolon (i.e., “;value;value;”)\n   b. If the value is NULL, preserve the null value\n2. Update values for existing data as follows:\n   a. If value is non-NULL, start and end the string with a semicolon, as long as the string does not already start/end with a semicolon (i.e., avoid introducing duplicate semicolons at the start/end of a string)\n   b. If value is NULL, preserve the null value.","Admit_Reason_Code \nChief_Complaint_Code \nDiagnosis_Code \nProcedure_Code","The character limit for these columns has increased to VARCHAR(8000).\n","Yes\n10/27/17","N/A","Yes\n01/25/18","Yes"]
[3,null,"Follow-up Needed","Low","Enhancement","Unit Processing\n\nMeasurement values are pulled from the OBX-5 field. Units are pulled from OBX-6.2. Some sites are sending Units values in OBX-6.1 so unit fields are showing NULL in ESSENCE and Processed tables.","No processing changes have been made at this time. Community will need to determine whether processing should be updated to accommodate units stored in OBX-6.1.\n\nReview of data suggests minimal impact.","Age_Units_Calculated                   \nAge_Units_Reported                      \nInitial_Temp_Units                         \nInitial_Pulse_Oximetry_Units                     \nHeight_Units                     \nWeight_Units                    \nSystolic_Blood_Pressure_Units                  \nDiastolic_Blood_Pressure_Units                \nSystolic_Diastolic_Blood_Pressure_Units","Investigation revealed that measurements can be calculated from an str_ field independent of whether units is populated. \n\nMeasurement values are calculated from the measurement \"str_\" fields independent of whether a unit was included in the message.\n\nImpact Assessment: Affects each field uniquely (for all sites) as follows\nAge_Units_Calculated (0.000%)                  \nAge_Units_Reported (14.964%)                      \nInitial_Temp_Units (0.574%)                        \nInitial_Pulse_Oximetry_Units (0.473%)                     \nHeight_Units (0.984%)                     \nWeight_Units (2.552%)                    \nSystolic_Blood_Pressure_Units (4.575%)                  \nDiastolic_Blood_Pressure_Units (4.456%)               \nSystolic_Diastolic_Blood_Pressure_Units (0.622%)\n\nTechnical Committee Comments 11/27/2018: OBX-6.1 is the location where unit code should actually be placed according to the PHIN Messaging Guide. It's usage is \"R\" while 6.2 is the OPTIONAL text description of the code. OBX-6.1 should be used instead or in hierarchy. Additional clarification is needed for the comment about the String field being used, specifically where the str_ value is pulled from\n\nThere was a decision to keep the functionality as is on 12/3.","Pending Discussion","N/A","For Future Consideration","For Future Consideration"]
[4,"BA-4459, \nBA-4259,\nBA-4233,\nBA-4232","Code Fixed; Historical Update TBD","Low","Bug Fix","Combo Field Logic\n\nCombo fields were only populated for data type “CE” or “CWE” and only if information is sent in .1, .2, .4, or .5.  Does not include instances where a message only contains data as “CE” or “CWE” with info sent in the .9 and does not include instances where a message includes chief complaint data of type “TX”.","Updated processing to include all components into the combo field and populate combo when Chief_Complaint_Type=\"TX\".","Admit_Reason_Combo\nChief_Complaint_Combo\nDiagnosis_Combo\nInitial_Acuity_Combo\nMedication_Combo\nProblem_List_Combo\nProcedure_Combo\nProvider_Type_Combo","Combo fields are not wrapped in semicolons but are concatenated with semicolons. \n\nImpact Assessment: In progress.\n\nNeed to discuss patching Archive data.\n\nThe Chief_Complaint_Combo field update was included in the PHIN Messaging Guide 2.0. ","Yes\n02/07/18","N/A","For Future Consideration","For Future Consideration"]
[5,"BA-3955,\nBA-3956,\nBA-3957,\nBA-3958,\nBA-3959\nBA-3960","Pending Discussion/Feedback","Medium","Enhancement","C_Death Processing\n\nSites sending values in PV1-36.1 that were not recognized by NSSP processing and C_Death was incorrectly set to 'No'.","Update to C_Death Processing in Mirth to include additional values from PV1-36.1. \n\nUpdated processing will set C_Death to \"Yes\" IF:\n   1. PID-30.1 (Patient_Death_Indicator) = First letter of \"Y\" and/or\n   2. PID-29.1 is not null and/or\n   3. PV1-36.1 contains \"20\", \"22\",\"23\",\"24\",\"25\",\"26\",\"27\",\"28\",\"29\", \"40\", \"41\" or \"42\"\nELSE set to “No”.","C_Death","When DischargeDisposition involves death mapping, you may see different values than expected in other death-related fields. This is because other death fields process the value from the last message with same ESSENCE ID, not the last non-null value (as DischargeDisposition does). Other death-related fields that may be impacted by this include:\n     - C_Death\n     - Death_Date_Time\n     - C_Death_Source\n\nImpact Assessment: 81,105 records or 0.004% of all messages across all sites.\n\nTechnical Committee Comments 11/27/2018: Data providers are only asked to say when a death did occur, not if it did not occur. If they do not say yes, it is unknown whether a death occurred or whether we didn't get the information. It would be more accurate to have a NULL value when a value indicating a death occurred is not present.\n\nNeeds further discussion with Technical Committee. (An example of a potential issue is as follows: If \"Yes\" is sent in the first message and \"NULL\" is sent in the second message, ESSENCE will keep the value in the second message.)","Yes\n10/25/17","N/A","Yes\n04/06/18","Yes\n04/20/18"]
[6,null,"Code Fixed; Historical Update TBD","Low","Bug Fix","Chief_Complaint_Segment\n\nChief_Complaint_Segment was not fully populating when Chief_Complaint_Type='TX'.","Updated Chief_Complaint_Segment Processing in Mirth to include the full OBX segment when OBX-2 = 'TX'.","Chief_Complaint_Segment","Action was taken to correct prospective data. Patching historical data can be considered a future enhancement discussion, but is currently low priority.","Yes\n02/07/18","TBD","TBD","TBD"]
[7,"BA-4258, \nBA-3818,\nBA-4079","Code Fixed; Historical Update TBD","Medium","Bug Fix","NULL Repeating Fields\n\nIdentified an issue in processing repeating fields such that if an empty field repeated, a semicolon would populate instead of a null value. ","Changed Mirth processing to ignore null values sent in repeating fields such that we do not see values of \";\" in concatenated fields. ","Admit_Reason_Description\nAdmit_Reason_Segment\nChief_Complaint_Code\nChief_Complaint_Text\nDiagnosis_Code\nDiagnosis_Description\nDiagnosis_Segment\nDiagnosis_Type\nDiagnosis_Priority\nTriage_Notes\nRace_Code\nRace_Description\nRace_Segment\nEthnicity_Code\nEthnicity_Description\nEthnicity_Segment\nInitial_Temp\nStr_Initial_Temp\nInitial_Temp_Units\nProcedure_Code\nProcedure_Description\nProcedure_Segment\nClinical_Impression\nProblem_List_Code\nProblem_List_Description\nProblem_List_Segment\nInitial_Acuity_Code\nInitial_Acuity_Description\nProvider_Type_Code\nHospital_Unit_Code\nHospital_Unit_Description\nSmoking_Status_Code\nMedication_Code\nPregnancy_Status_Code\nPregnancy_Status_Description","Need to discuss patching Archive data. \n\nTechnical Committee Comments 11/27/2018: This would be important for retrospective data analyses.\n\nCDC will investigate LOE and volume. ","Yes\n01/01/18","N/A","TBD","N/A"]
[8,"BA-4230","Follow-up Needed","TBD","Bug Fix","Truncated Admit Reason Code Values\n\nAfter the Admit_Reason_Code field length was extended to 8000, it was noted that Mirth is still sending only the first 255 characters of Admit_Reason_Code to the Processed tables.","An investigation is underway to determine how frequently and under what conditions this value is being truncated.","Admit_Reason_Code","Impact Assessment: Affects 0.01% of total messages across all sites. ","Pending Discussion","TBD","For Future Consideration","For Future Consideration"]
[9,"BA-4264","Follow-up Needed","Low","Bug Fix","C_Patient_Age, C_Patient_Age_Years\n\nThe current C_Patient_Age_Years calculation does not account for leap years, thus, records with close birth and visit dates are affected by the extra days gained from leap years. ","No processing changes have been made at this time.","C_Patient_Age\nC_Patient_Age_Years","ESSENCE uses a separate algorithm for determining Patient Age. The ESSENCE algorithm does not take leap years into account. ","For Future Consideration","For Future Consideration","N/A","N/A"]
[10,"BA-4262","Code Fixed; Historical Update TBD","Low","Bug Fix","Initial_Temp, Initial_Temp_Units\n\nInitial_Temp in ESSENCE was being sent as a concatenation of Intial_Temp and the first character of Initial_Temp_Units. This impacted the normalization process applied in ESSENCE to produce the Initial_Temp_Calc.","Updated values being sent from Processed to ESSENCE for Initial_Temp and calculation of Initial_Temp_Calc in ESSENCE. Processing now sends Initial Temp and the whole value of Initial_Temp_Units.\n\nESSENCE is adding all standard unit values carried in OBX-6 to their normalization process and reviewing ways to patch retrospective data to degrees Fahrenheit based on specified range of measurements.","Initial_Temp\nInitial_Temp_Units\nInitial_Temp (ESSENCE)\nInitial_Temp_Calc (ESSENCE)","Impact Assessment: Impacts approximately half of all visits. \n\nTechnical Committee Comments 11/27/2018: Temperature information is not often used and is probably not often used retrospectively. It would be nice to clean up though.","N/A","Yes\n01/30/18","N/A","Not Started"]
[11,null,"Follow-up Needed","Low","Enhancement","Numeric Measure Field Processing \n\nMirth sends appropriate value from the OBX segment as a string over to SQL, where the remainder of the processing happens. The Insert_XX_Processed stored procedure uses the TRY_CAST function to convert the string to decimal(6,2) data type. If the decimal is too large, or not in the correct format to be converted, the function returns NULL. This is why there are records with values in the string measure field (i.e., Str_Height) but NULL in the numeric measure field (i.e., Height).","No processing changes are planned at this time.","Initial_Temp\nHeight\nWeight","While it is the string field we pass to ESSENCE, ESSENCE processing will also reject outlier values.\n\nTechnical Committee Comments 11/27/2018: If str_ is the field passed onto ESSENCE, this is not a big deal.\n\nRevisit the discussion to reprocess data after higher priority issues have been addressed.","N/A","N/A","N/A","N/A"]
[12,null,"Code Fixed; Historical Update TBD","Low","Enhancement","Chief Complaint Processing\n\nWhen two chief complaint segments are sent as two different data types, Mirth processes both OBX segments according to the data type found in the first message.","Update Mirth processing to process OBX Chief Complaint segments individually based on the OBX-2 value associated with the individual OBX segment carrying the chief complaint.","Chief_Complaint_Code\nChief_Complaint_Text\nChief_Complaint_Type","As less than 1% of all NSSP records were affected by this issue, NSSP will not be reprocessing retrospective data at this time.","Yes\n05/15/18","N/A","For Future Consideration","For Future Consideration"]
[13,null,"Follow-up Needed","Low","Bug Fix","Coded Data Type Processing\n\nFor elements defined as coded data elements, Mirth processes the raw segment as data type CWE regardless of the data type value in OBX-2 (or element #2 of the appropriate HL7 segment). The exception to this rule is Chief Complaint, which is processed according to the value sent in OBX-2.\n\nFor Example: Initial Acuity is a CWE data type. If the raw segment was reported with OBX-2 = 'TX' and contained a single text string in OBX-5.1, the data would be stored in the Initial_Acuity_Code field.","No change needed.","Initial_Acuity_Code\nInitial_Acuity_Description\nAdmit_Reason_Code\nAdmit_Reason_Description\nDiagnosis_Code\nDiagnosis_Description\nProblem_List_Code\nProblem_List_Description\nProcedure_Code\nProcedure_Description\nProvider_Type_Code\nProvider_Type_Description\nMedication_Code\nMedication_Description","Impact Assessment: In progress.\n\nTechnical Committee Comments 11/27/2018: Data should be processed based on what is communicated in the message rather than what is expected for a particular type of value.","N/A","N/A","N/A","N/A"]
[14,null,"Code Fixed; Historical Update TBD","Low","Bug Fix","ESSENCE Order of Message Processing \n\nUntil March 13, 2017, if messages with \"earlier dates\" came in after the more recent messages, the chief complaint was not getting updated to reflect this earlier \"first non-NULL chief complaint\".","A fix was put in place such that prospective processing of records will yield an ESSENCE visit that has the \"first non-null chief complaint.\"","C_Chief_Complaint\nChiefComplaintOrig (ESSENCE)\nChiefComplaintParsed (ESSENCE)","Similar to ESSENCE Enhancement Issue 57 ","N/A","Yes\n03/13/17","N/A","N/A"]
[15,null,"Complete","Low","Bug Fix","Facility Type Processing (standard and local values)\n\nFacility Type OBX segment has a data type of CWE such that facility type code data may be reported with both standard data and local data (i.e., a standard code value in OBX-5.1 and a local code value in OBX-5.4).  Similarly, facility type description data may be reported with both standard data and local data ((i.e., a standard description in OBX-5.2 and a local description in OBX-5.5).  \n\nTypically, processing rules are such that NSSP process will store the first non-null value found in  \n-OBX-5.1, OBX-5.4 for Facility_Type_Code\n-OBX-5.2, OBX-5.5 for Facility_Type_Description\n\nHowever, the NSSP process is concatenating the standard and local data.","Based off community feedback Facility Type and Facility Type Description are to be hierarchically defined (as originally specified) to pull from standard if non-null, else local:\n• For Facility Type, select first non-null from OBX-5.1 (i.e., standard code) , OBX-5.4 (i.e., local code)  \n• For Facility Description, select first non-null from OBX-5.2 (i.e., standard description) , OBX-5.5 (i.e., local  description)  \nThis should be applied prospectively only.","Facility_Type_Code\nFacility_Type_Description\nFacility_Type_Segment","Impact Assessment: Preliminary assessment of affected data: 3.5% of total records across all sites (excluding Legacy data)\nNote: 88% of visits in 2018 have a C_Patient_Class based on reported patient class (88% PV1 patient class, 11% MFT, 1% OBX Facility Type). \n","Yes \n11/16/2018","N/A","No","N/A"]
[16,null,"Complete","Low","Enhancement","Facility Type Processing (multiple facility type segments sent)\n\nFacility Type has a cardinality of 1:1, however, there are instances where incoming data has more than 1 OBX facility type being reported.\n\nNSSP processing is concatenating Facility Type data “across segments”.   For ex, if two OBX facility type observations were sent, each having a standard code (OBX-5.1) and a standard description (OBX-5.2), the resulting data would have a facility_type_code value that was a concatenation of the 2 separate facility_type_code values found in OBX-5.1 (across these 2 segments). Similarly, the facility_type_description value would be a concatenation of the 2 separate facility_type_description values found in OBX-5.2 (across these 2 segments).","A fix was implemented in Staging to only use the first reported OBX segment. Production updates were held pending input from the Technical Committee.\nThe Technical Committee recently decided that NSSP process should be updated such that will keep only the contents from the first segment when incoming messages have more than one OBX Facility Type reported. This will only be applied prospectively.","Facility_Type_Code\nFacility_Type_Description\nFacility_Type_Segment","Impact Assessment: Preliminary assessment of affected data: 0.07% of total records across all sites (excluding Legacy data). \n\nSince this is technically an error on the data provider side (not following the PHIN messaging guide rules), this could also be resolved by requiring people work with data providers to resolve this issue. The Technical Committee recommends NSSP evaluate the LOE to make this fix and  resources required. If the benefits do not outweigh the LOE, it will be determined a data provider issue.","Yes \n11/16/2018","N/A","No","N/A"]
[17,null,"Follow-up Needed","Low","Enhancement","Body Mass Index Processing\n\nNSSP currently processes Body_Mass_Index using OBX segment(s) with LOINC code 59574-4. This is the LOINC code for \"the percentile of the body mass index\". If sites send OBX segment(s) with LOINC code 39156-5, the segment will not be ingested.","There is discussion around changing processing to include OBX segment(s) with LOINC code 39156-5, which is the LOINC code for \"body mass index by units of kg/m2.\"","Body_Mass_Index\nStr_Body_Mass_Index","As the PHIN Messaging Guide would first need to be updated to reflect this addition, no decision has been made to update Body_Mass_Index processing at this time.\n\nTechnical Committee Comments 11/27/2018:If  LOINC 39156-5 was ever an approved value,  it should be supported as facilities rarely update their value sets. If not, it should not be considered in the processing as they are not conforming to the specifications.","Pending Discussion","N/A","For Future Consideration","For Future Consideration"]
[18,null,"Pending Discussion/Feedback","Medium","Enhancement","Travel History ESSENCE Processing\n\nESSENCE currently processes Travel_History using the value from the last message received for the ESSENCE visit (even if the last message received contains a NULL value). This sometimes results in NULL values for ESSENCE Travel_History even though the facility sent  a valid, non-null value for the visit in earlier messages.","NSSP is considering altering the ESSENCE processing such that the last non-NULL value is ingested instead of the value from the last message received.","Travel_History","CDC will investigate background information on first non-null items that may need further discussion. ","N/A","Pending Discussion","N/A","Pending Discussion"]
[19,null,"Follow-up Needed","Low","Enhancement","C_Patient_Class Processing\n\nCurrent processing is as follows:\n     - use PV1 if standard or mappable\n     - else use OBX fac type if standard\n     - else use the patient class associated with the primary facility entry in the MFT\n\nThis manner of processing makes it difficult to distinguish the different facility types among associated, non-primary facilities.","Suggested update to processing is as follows:\n     - use PV1 if standard or mappable\n     - else use OBX fac type if standard\n     - else use the patient class associated with the facility type entered for that exact facility in the MFT (even if the facility is associated, and not primary).","C_Patient_Class","This issues raises another related question of whether associated facilities  should be able to have a different patient class from the primary. This is a question for associated facilities that contain IDs that are the same as the primary facility's ID and associated facilities that contain IDs that differ from the primary facility's ID. ","Pending Discussion","N/A","N/A","N/A"]
[20,null,"Follow-up Needed","Low","Bug Fix","Leading semicolon in Diagnosis_Description\n\nA leading semicolon is being populated in Diagnosis_Description. ",null,null,"Diagnosis_Description is not being sent to ESSENCE, so the leading semicolon should not have impacts to query performance in the application. \n\nImpact Assessment: Affects 31.2% of total message volume across all sites. ","Yes\n10/2/2018","TBD","TBD\nPending review by Technical Committee","TBD"]
[21,"BA-3754","Pending Discussion/Feedback","High ","Enhancement","Chief Complaint Exclusion Terms in ESSENCE\n\nInvalid chief complaint values being sent in the data are preventing visits from being categorized appropriately in ESSENCE.\n\nFor example: A facility sends the value \"UNKNOWN\" in the chief complaint for record 1 of a visit.  Record 2 then contains the real chief complaint.  ESSENCE stores the value from record 1 in the chief complaint (i.e., stores \"UNKNOWN\"). ","Suggested update to Chief Complaint Processing in ESSENCE to exclude the following terms:\n\n“”\n;\n;;\nNull\nUnknown\nn/a\nna\nunk\ned visit\ned\ner\nsee tsheet\nchief complaint not present\nadvice only","ChiefComplaintOrig\nChiefComplaintParsed","Impact Assessment: This issue affects approximately 0.2% of visits in ESSENCE.\n\nTechnical Committee Comments 11/27/2018: This should be discussed and list of terms reviewed with community, maybe the SDC. It seems there are 2 tiers of values: Those which are a way of saying \"missing\" (like unknown) but others, while not super informative are not the same as missing and should be included in the visit record unless something more informative comes along in a later message. The non-informative values should be kept in the CC Hx field. Also, Staging ESSENCE is used to validate data received from new providers. It is helpful to see what they actually sent in CC rather than have it converted to missing. If they send something (even if non-informative) we may have different f/u than if it is completely NULL.\n\n7/30/2018: Fix would be global (not on a hospital by hospital basis). “Unknown” should not be treated as a “non-null” when collapsing visits. Are there any other terms in addition to “Unknown” that should be included in this fix? List of additional terms shared with JHU. Two ways to perform change (1) alter history system to treat “unknown” as a NULL or (2) replace field value of “unknown” with NULL. Option 2 would require less processing. \n\n5/18/2018: Are there other terms that the community has shared with us to date that reflect \"unknown\"? Could use a pre-processing step to wipeout \"UNKNOWN\" and convert to NULL then let history system remain unchecked. If JHU took NSSP ChiefComplaintOrig and set to NULL when it had an \"UNKNOWN\" term - impact would be data quality reports would consider that an incomplete field.\n\n4/30/2018: JHU can modify the history system to treat \"UNKNOWN\" as a null."]
[22,null,"Follow-up Needed","Medium","Enhancement","Timeliness Reports in ESSENCE and difference in approach in DQ reports\n\nDQ reports run off NSSP Archive data\nBased on the difference between visit datetime (c_visit_datetime)  and the *first* arrival datetime (arrival_date_time) of a message associated with that C_Biosense_ID.  Note time zone is considered during the calculation.  The arrived datetime  is adjusted to reflect the time zone associated with the Site.\n\nESSENCE DQ\nBased on the difference between visit date (date) and time (time), and the message date time (messagedatetime),  where the message date time is the messagedatetime associated with the most recent message.  No time zone adjustments.\n\nNote- The timeliness in ESSENCE does have to change to such that the “first message” is used.  Also, input on what the calculation should be based on  (message date?  Arrived date?) in ESSENCE. We have this on list for discussion w/ Tech Committee.   We are working  on an ESSENCE changes tab (akin to data flow enhancements tab).\n",null,null,"Technical Committee Comments 11/27/2018: While arrival time can sometimes be complicated by factors other than the original data provider's timeliness (e.g., issues with receipt/processing/transmission from state/local to NSSP), it is more relevant to the availability of data than messagedatetime. For various reasons, messages may be generated but then sent in batches, or they may be recreated to fill-in a gap. Arrival time should be used. The timeliness calculation approach done in the DQ reports is the right way to do it and the tools in ESSENCE (or whatever dashboards are created) should reflect this. There may not be a need for DQ tools in ESSENCE IN ADDITION to developing DQ dashboards."]
[23,"BA-4542",null,"Medium","New Development","Updates to Race / Ethnicity Processing","Possible updates to Race/Ethnicity calculations based on changes to census reporting and updates to the PHIN guide and PHINVADS value sets.","Race_Code\nRace_Description\nEthnicity_Code\nEthnicity_Description","Technical Committee Comments 11/27/2018: Need more detail about what changes are being made and impacts.","Pending Discussion","N/A","N/A","N/A"]
[24,"BA-5286","Complete","High ","Bug Fix (MFT)","MFT Vendor Information Conversion Issues\n\nWhen converting information from the MFT Excel templates to the new MFT Module database, incorrect values were observed for:\n* Vendor_Name\n* Vendor_Software\n\nNote that a vendor information mapping file was produced by the Data Quality Workgroup to facilitate this conversion.","1.  Remove incorrectly mapped vendor information for each facility but exclude facilities where the Site Administrator has updated vendor information since the MFT Module was deployed.\n\n2.  Convert vendor information using the vendor information mapping file from the Data Quality Workgroup and directly update the MFT module database such that:\n-IF a standard vendor entry is available then\nVendor_Name = Standard Vendor Name\n-IF a standard vendor entry is not available then\nVendor_Name = Unable to convert: <concatenated info from 3 columns in old MFT>\nVendor_Software = null\nVendor_Effective_Date = Date_Activated (for Active facilities), else null.","Vendor_Name\nVendor_Software","MFT Module Application Update? N/A\n\nMFT Data Updated? Complete in Production on 11/18/2018","N/A","N/A","N/A","N/A"]
[25,"BA-5260","Complete","High ","Bug Fix (MFT)","MFT Feed_Name \"unknown\" Values\n\nFacility data stored in the MFT Module database had feed_name values = \"unknown.\"\n\nNote that no data was lost when converting from the MFT Excel Templates to the MFT Module database.  In this instance, the feed_name value was \"unknown\" in the MFT Excel Template which translated to an \"unknown\" value in the MFT Module.","Processed and Staging tables were used to obtain unknown Feed_Name values from max(Arrived_Date).  Using these, update query was applied to MFT when: \n1. Primary_Facility='Y' \n2. Facility_Status='Active', 'Inactive', or 'Onboarding' \n3. Feed_Name is null\n\nNSSP will also implement regular reviews to compare Feed_Name in MFT to XX_Processed Feed_Name because feed names can change over time.\n\n1246 facilities met this criteria; Approx 899 were updated.","Feed_Name","MFT Module Application Update? N/A\n\nMFT Data Updated? Complete in Production on 11/5/2018","N/A","N/A","N/A","N/A"]
[26,"BA-5156","In Progress","High ","Enhancement (MFT)","MFT Views\n\nMFT displays the change made by the site administrator that is pending review.\n\nFor example: A facility changes from Onboarding to Active. MFT Facility_Status = Active when, in reality, Facility_Status = Onboarding (in data processing tables and ESSENCE) until approved by OB and ADM. \n\nThis will happen with all review reasons (i.e., the MFT will display the value input by user, but the information is not updated on the backend until OB and ADM approve). There is no easy way to see what values were previously in the MFT facility form prior to changes made by site to compare \"last complete\" record to records that are pending facility review.","The resolution contains 2 parts:\n\n(1) Views/displayed values need to be clarified in the MFT QSG  and MFT companion guide\n\n(2) A view of a given facility's \"last complete\" record needs to be made available (See Issue #10 in AMC Enhancements for more information).","Facility_Status","MFT Module Application Update? N/A\n\nMFT Data Updated? N/A\n\nChanges to the MFT QSG are being reviewed.","N/A","N/A","N/A","N/A"]
[27,"BA-5151,\nBA-5219","In Progress","High ","Bug Fix","MFT Vendor Effective Date\n\nA defect currently exists for Vendor_Effective_Date in which the information stored for each facility is incorrect due to the structure of the database. \n\nThe current workflow is as follows: Vendor_Name and Vendor_Software combination are tied to a specific Vendor ID. Vendor_Effective_Date is tied to a VendorID. If a user adds or changes a Vendor_Effective_Date to an existing Vendor_Name and Vendor_Software combination, the Vendor_Effective_Date will be updated for all existing facilities with the same Vendor_Name and Vendor_Software  combination.","Update Vendor Effective Date to meet requirements: capture the date that a primary facility started using a specified EHR vendor. (EHR vendor is Vendor_Name on the MFT facility information page.)","Vendor_Name\nVendor_Software\nVendor_Effective_Date","MFT Module Application Update? Expected to be part of January 2019 AMC release\n\nMFT Data Updated? TBD","N/A","N/A","N/A","N/A"]
[28,"BA-5224, \nBA-5267","In Progress","High ","Bug Fix","Field length update for Medication_Code, Medication_Description, Medication_Segment.\n\nCurrently, Mirth will truncate medication values received in the HL7 message to match the “Mirth length” field.  It may make sense to expand some of these field lengths. The need to avoid truncation of data if possible is important while still being conservative with length for performance reasons. ","Field lengths in the Archive processed tables will be updated as follows in November 2018:\n\nMedication_Code will be increased from 50 to 2000\nMedication Description will be increased from 600 to 4000\nMedication_Segment will be increased from 800 to 8000\n\nMedication_List and Medication_Combo are staying at the current length of 8000. ","Medication_Code\nMedication_Description\nMedication_Segment","The existing data in the Archive Processed table was assessed to determine minimum values and how often received values exceeded the available column length. A subset of the messages was processed containing truncated data values (approx. 17K messages across a couple of sites) to a temporary Mirth table to obtain the metrics to help direct an appropriate resolution.\n\nUpdates to these fields are complete. The team is investigating additional fields to recommend changes.  Once that is complete all changes will be moved to Production together.  ","Yes\n10/2/2018","N/A","Yes","N/A"]
[29,null,"In Progress","High ","Bug Fix (MFT)","MFT Associated Facility ID Conversion Issue\n\nWhen non-primary facilities were converted to associated facilities, the new field “map to primary” was set to “Y” by default for all non-primary facilities. The Stored Procedure that performs Crosswalk Inserts is configured to reject duplicate entries.  However, in the observed case, the “map to primary” = “Y” for converted facilities caused an issue due to a change in Primary Facility ID UUID. Ultimately, duplicate rows were inserted into the crosswalk.","Modify the “map to primary” values for Associated Facilities that were converted from non-primary facilities in the old MFT framework such that:\n• If Associated Facility ID UUID = Primary Facility ID UUID, then set “map to primary” = “N/A”\n• If Associated Facility ID UUID <> Primary Facility ID UUID, then set “map to primary” = Y or set “map to primary” = N (if and only if the existing operational crosswalk verifies one of the assumptions)","Input_FacilityID_UUID\nOutput_FacilityID_UUID\nMap_to_Primary","The Stored Procedure stepped through the Operational Crosswalk updates as follows:\n\n(1) The original state mapped the Original ID to the Original ID.\n(2) Due to the change in Primary Facility ID UUID, a new entry was added to the operational crosswalk that mapped the New Facility ID UUID to itself. \n(3) Any associated facilities that did not already exist in the operational crosswalk were inserted. The other rows in the crosswalk did not match the values for the associated facility, so the insert was accepted. The Original ID was mapped to the New ID.\n(4) The Output Facility ID was then updated for applicable rows and there was not another check for duplicates since the check was already conducted. The Output Facility ID for the primary facility was updated to the New Facility ID UUID so the result was the Original ID mapping to the New ID causing a duplicate entry.\n\nMFT Module Application Update? N/A\n\nMFT Data Updated? The duplicate rows issue was corrected by Onboarding team. There is still an outstanding ticket to correct the underlying \"map to primary\" value for all facilities that could be affected down the road. ","N/A","N/A","N/A","N/A"]
[30,null,"Follow-up Needed","Medium","Bug Fix (MFT)","Simultaneous Change in Primary Facility ID UUID and Facility Status (from Onboarding to Active)  \n\nWhen the user attempts to change both Primary Facility ID UUID and Facility Status, the Facility Status on the Operational Crosswalk is not updated for the first row (i.e., for the original entry).","Short-term Solution\n• Manually update operational crosswalk to correct the Facility Status value on the first row\n• (TBD) Do not approve records where the Primary Facility ID UUID and Facility Status are changed at the same time\n\nLong-term Solution\n• (TBD) Modify UI to prohibit Site Administrators from changing the Facility ID UUID and the Facility Status at the same time\n• (TBD) Modify the insert to Operational Crosswalk stored procedure to update both Facility ID UUID and Facility Status at the same time","Facility_Status\nInput_FacilityID_UUID\nOutput_FacilitiID_UUID","MFT Module Application Update? TBD\n\nMFT Data Updated? Complete","N/A","N/A","N/A","N/A"]
[31,null,"Open","Medium","Bug Fix","Update C_Patient_Age to check for negative values\n\nThe NSSP  C_Patient_Age is hierarchically defined as follows\nSelect the first non-null value from:\n* C_Visit_Date - Birth_Date**\n* Age_Reported \n* Age_Calculated \n\n** When performing the calculation, store the numeric year value if the value >= 2 years (round down to the nearest integer); else, store the number of months and round down to the nearest integer (i.e., 4.9 rounds to 4; 5.2 rounds to 5). If the number resolved is greater than 150 years the Birth_Date_Time column will be set to NULL and the calculation will continue down the hierarchy to Age_Reported or Age_Calculated.\n\nC_Patient_Age/C_Patient_Age_Units in Processed data is used in the ESSENCE algorithm to set “Age”.  The ESSENCE process checks for invalid ages (<0, >120, and NULLs) in C_Patient_Age, and replaces the value with -1 before storing in the “Age” column in ESSENCE.  This is done so that the ESSENCE process can then map ages with values of -1 to an “unknown” category for queries running off of the base table.  An internal mapping table is leveraged to perform this on the fly mapping from -1 to “unknown”.\nThe NSSP C_Patient_Age process currently does not check for “negative” values that result from an age calculation based on Birth_Date_Time.   As a result, the ESSENCE ingestion includes C_Patient_Age values that are negative, deemed as invalid per ESSENCE, and the ESSENCE Age is set to -1.      \n\nThe NSSP process is currently only checking for unusually old ages with values > 150.  As with the >150 check, an <0 check can be added such that Birth_Date_Time is set to NULL, forcing the C_Patient_Age algorithm to advance to using Age_Reported, or Age_Calculated.","If C_Visit_Date_Time - Birth_Date_Time is <0, set the Birth_Date_Time value to NULL such that the calculation continues down the hierarchy to Age_Reported or Age_Calculated (i.e., move down the hierarchy and try to pass a valid value that may have been populated within reported age to ESSENCE).","C_Visit_Date_Time - Birth_Date_Time\nAge_Reported \nAge_Calculated \n","Technical Committee Comments 11/27/2018: It would be good to force the hierarchy when invalid values are detected based on calculations since valid values may be sent in other fields.","TBD","N/A","TBD","N/A"]
[32,null,"Open","Medium","Bug Fix","Update C_Patient_Age processing to mirror ESSENCE processing for values >120\n\nThe ESSENCE process checks for invalid ages (<0, >120, and NULLs) and replaces the value with -1 .  This is done so that the ESSENCE process can then map ages with values of -1 to an “unknown” category for queries running off of the base table.  An internal mapping table is leveraged to perform this on the fly mapping from -1 to “unknown”.\n\nAt this time, the NSSP process only sets the Birth_Date_Time to NULL if the C_Vist_Date_Time-Birth_Date_Time resolved value is >150.   Therefore there may be ages sent to ESSENCE that are between 120-150 (sent via NSSP) but which are being categorized as invalid per ESSENCE rule (age > 120).","Should NSSP processing logic be changed to mirror ESSENCE processing (check for >120), or should ESSENCE processing logic be changed to mirror NSSP checks (check for >150)?","C_Visit_Date_Time - Birth_Date_Time\nAge_Reported \nAge_Calculated \n","Technical Committee Comments 11/27/2018:According to Wikipedia, the oldest person with known age was almost 123, followed by 119 and a bunch of 117s, so 150 seems a bit extreme. Maybe a compromise and switch both to 125. I think NSSP should be <= to ESSENCE value because if ESSENCE is going to throw the value out anyway, NSSP should be looking for a potentially valid value to pass along using its hierarchy rather than picking one just to have ESSENCE throw it out. NSSP value should be changed to 120. Theoretically if a person is really that old, the other values will match up. ","TBD","N/A","TBD","N/A"]

{"sheet":"ESSENCE Enhancements","index":2,"n_rows":63,"n_cols":10,"rows_kept":63,"cut":false,"hidden":false,"merged":[[0,0,0,12],[1,8,1,9],[1,0,1,1],[1,2,1,3],[1,4,1,7]]}
["ESSENCE Enhancements"]
["Issue #",null,"Status and Priority ",null,"Enhancement Summary",null,null,null,"Implementation Status"]
["Issue #","JIRA Ticket","Status","Priority ","Issue Type","Category","Enhancement Description","Notes","Prospective Fix Only?","Retrospective Data Patched?"]
[1,"BA-4511","Follow-up Needed","High ","Enhancement","Data Quality","Develop basic or \"start up\" ESSENCE dashboards available to all new users","12/12/2018: Follow up discussion will be held to identify base 1. Users have access via Staging. \n\n11/27/2018 (Technical Committee Comments): Further discussion will need to be held to discuss the feasibility. A menu of requested pre-existing dashboards would be helpful for the community. \n\n10/22/2018:The intended use of the dashboards needs to be shared with the Technical Committee. The Technical Committee can then help determine content. The dashboards are currently set up in Staging ESSENCE; JHU to find a way to share with the technical committee (The data the dashboards are using may not currently be accessible to the Technical Committee). \n\n7/30/2018: JHU deployed an example start up dashboard in the Staging ESSENCE application. Next Steps:\n• CDC to review example and recommend updates/additional functionality\n• JHU to provide overview of dashboard during routine call\n\n5/18/2018:Set up dashboards so users can filter by state. Issue is there may need to be different permissions for different people. Could be helpful to hear example use case. Next step would be for JHU to turn on example.\n\n3/19/2018:JHU needs additional clarity needed around requirements; may be able to leverage work already done for a site."]
[{"$f":"A4+1","v":2},"BA-3633",null,"High ","Enhancement","Data Processing","Develop custom regions (\"super regions\") within ESSENCE to allow for new groupings of data and/or to limit data available within a custom region (Related to Issues 20 and 21)","12/12/2018: Super region request will need to be clarified and user requirements identified to develop technical solution. A workgroup will be identified to identify use cases. \n\n11/27/2018 (Technical Committee Comments): Technical Committee would like examples of the usage of \"super regions\". Ticket NTA-2618 was implemented and resolved and the user can filter by facility location if facility location is the datasource used for the original query. \n\n10/29/2018:Need to clarify use case to JHU. Tickets were identified that relate to this request (NTA-2828, NTA-2618, NTA-2616, NTA-2579, NTA-2504, NTA-2225, NTA-1620, NTA-1343, NTA-1272, NTA-780). The Technical Committee may have additional input on use cases.\n\n6/14/2018: Explore need for this requirement with the enhanced data access controls available in ESSENCE 1.21.\n\n5/18/2018:MyFilters provides functionality to create custom regions. Problem arises with data access control within data details page. JHU suggested creation of new data source. The problem is that every record can only be assigned to one super region.\n\n3/19/2018:JHU may be able to leverage 1.21 access controls. JHU may also be able to leverage current work towards \"MyFilters\" to set up something akin to a custom region."]
[{"$f":"A5+1","v":3},"BA-4517","Follow-Up Needed","Medium","Enhancement","Data Processing","Include the FL word alert functionality in the implementation of ESSENCE","6/14/2018: Ask JHU about results of speed test. Determine if it went well enough to deploy to all sites.\n\n4/30/2018:JHU needs to perform another speed test."]
[4,"BA-3727","Follow-Up Needed","High ","Bug Fix","Data Processing","Chief Complaint Processor:  Chief complaint of \"SI\" maps to substance inhalation in ESSENCE instead of \"suicidal intention\" - as a result, they are not mapped to the Suicide subsyndrome. Logic should be updated.","11/27/2018 (Technical Committee Comments):This issue is similar to a list of changes to be considered for Chief Complaint Processor. It was suggested to consider options to implement changes prospectively and retrospectively without major system impacts and potentially to consider a separate server for reprocessing.\n\n5/18/2018:Confirmed that prospective data is possible but retrospective fix would be difficult. From retrospective POV, is there someway to identify only records that would be affected? And if it's a small number, what would be the affect of processing those? Touch base with site to get feedback on their experience.\n\n4/30/2018:CCP Definitions can be modified.  Would probably be useful to have a playground dataset to use for CCP modification testing. "]
[5,"BA-3969","Follow-Up Needed","Medium","Enhancement","Data Processing","Processing Logic:  Modify processing to support additional history fields and consistent processing across related variables (includes identifying processing updates for companion fields - e.g., diagnosis code currently treated differently than diagnosis combo - and identifying history fields or options for variables like trigger event, admit reason, and chief complaint parsed)","6/14/2018: Summarize response CDC has received from syndromic surveillance community.\n\n5/18/2018:Fields were identified and CDC is working with community to prioritize.\n\n4/30/2018:This can be done.  Any additional history fields will add time to the processing load.  \n\n3/19/2018:NSSP working to identify affected fields and refine requirements for processing updates.  SDAs to make first attempt at organizing this work. Discuss \"trigger history\" on 3/26 JHU call."]
[6,"BA-4518","Follow-Up Needed","Medium",null,"Data Processing","Processing Logic:  Update Chief Complaint Processor (CCP)\n* ICD9/10, SNOMED codes?\n* \"Nebraska CCP\" (negation/abbreviation differences with current NSSP CCP)?","11/27/2018 (Technical Committee Comments):Issue #6 is related to Issue #4 and Technical Committee will need additional detail to evaluate. \n\n7/30/2018: Two parts (1) turn on Nebraska negation, would be a change in system (2) turn on CCP on history system, would be an addition to system. Both could be forward improvements. Nebraska negation can negate multiple terms at once (meaning, it’s best suit for hospitals that send lengthy chief complaints). Can do a search for negation words to get a feel for how many hospitals/records would be affected by this. Need to flesh out technical details, pros/cons, etc. \n\n6/14/2018: Follow up with JHU on if they were able to estimate how much CPU/Time it would take to perform CCDD type versions. Inquire if they turned Nebraska mode on for all sites.\n\n4/30/2018:Value found in turning on Nebraska mode and in using the History system fields in CCP.  The value of a CCDD type version would be interesting to investigate.  Will need to see how much CPU/Time it would take to perform all of those versions.\n\n3/19/2018: Need NSSP discussion to clarify requested enhancements to CCP."]
[7,"BA-4512","Pending Discussion/Feedback","Medium","Enhancement","Data Quality","Data Quality Alerts:\n1) Configure a data quality alert by facility that users can subscribe to when volume drops off or stops\n2) Configure a data quality alert that allows users to take advantage of all the time stamps in the data","11/27/2018 (Technical Committee Comments): Technical Committee would like to see alerts for significant positive or negative changes. Ability to subscribe to and review list of alerts (similar to \"myAlerts\" or DQ dashboard). Consideration should be given to hosting DQ tools within ESSENCE and/or outside of ESSENCE. \n\n10/29/2018:Need to determine the kinds of alerts the community would like to have. This enhancement can be done in a stepwise manner if necessary (i.e., create alerts for certain things the community identifies as a priority and then add additional alert options in the future as necessary).\n\n6/14/2018:Further discussion needed to determine the exact requirements for this feed volume alert.\n\n5/18/2018: Still need to determine what percent of dropped volume CDC wants to trigger alert on and subscription preferences. Option to add new detector \"reverse detector\" that performs search for records that are considered increases. Currently, detectors are only one sided, would need to make volume detector two sided to detect decreases (or any major fluctuation) as well. Need to answer questions, such as, how large of a fluctuation are we looking for (hard count or percent drop?), how would it affect large sites vs big sites, etc.\n\n4/30/2018:Need to determine what % of drop off in total volume would trigger alert. This can be done pretty easily.  Need to clarify if subscribe means an email subscription or just a new DQ page? Time stamp issue has been discussed.  Need to update the history system some to do that."]
[8,"BA-4017","Open","Medium","Enhancement","Data Quality","Data Quality: Add \"Factor\" for \"Percent received in 48 hours\" in addition to the existing 24 hour option","10/29/2018: Date was added to all the base tables in Staging and gives ability to look at date when record made it to ESSENCE for the first time. When database update is deployed to Production straightforward update to DQ calculation.\n\n6/14/2018:Follow up with JHU for an update regarding an enhanced timestamp that can be used for data quality.\n\n4/30/2018: This is fine to do once the better timestamp can be created for use in the DQ system.  "]
[9,"BA-2286","Follow-Up Needed","High ","Enhancement","Data Quality","Data Quality: Add additional variable to the DQ report in ESSENCE (need to determine which variables to add)","11/27/2018 (Technical Committee Comments):Further clarification needs to be provided on the list, DQ reports, completeness, and mapped values. \n\n9/10/2018:List sent to CDC and JHU of what additional variable to add to the DQ report in ESSENCE (based on feedback from the community).\n\n6/14/2018: Follow up on what feedback CDC has received from the community on this."]
[10,"BA-4096","Follow-Up Needed","High ","Enhancement","Data Quality","Data Quality: Enhance timeliness of reporting by making available the original datetime stamps for each visit and the last updated datetime stamps for each visit - \"Timestamp history field(s)\"","10/29/2018: Done in Staging.\n\n7/30/2018:Adding history system onto MessageDateTime or ArrivedDateTime. Need to keep track of when ESSENCE receives a message for the very first time. JHU knows the lift it would require but hasn’t performed the update yet."]
[11,"BA-4516","Follow-Up Needed","Medium","Enhancement","Data Quality","Data Quality tab: Add \"Site\" and \"Feed Name\" as a filterable option for DQ reports","11/27/2018 (Technical Committee Comments): Provided feedback on Issue #7 (DQ tools on ESSENCE) is related to Issue #11. \n\n10/29/2018:JHU to create a mockup.\n\n6/14/2018:ICF is working with ADM team to do this internally. Follow up with JHU on what their investigation revealed."]
[12,"BA-2285","Follow-Up Needed","Low","New Development","Data Quality","Create Data Quality reports in the Report Manager","11/27/2018 (Technical Committee Comments): Formal report generation and dissemination to parties outside of ESSENCE would not happen often, unless the report is being created to share issues with hospitals. Dashboards that may be saved might be a better solution. \n\n10/29/2018: JHU to review and determine LOE\n\n7/30/2018: Recent changes have been made to Report Manager. JHU to reinvestigate."]
[13,"BA-4461","Complete","Medium","Enhancement","Data Sources","Add New Data Source: DOD","11/27/2018 (Technical Committee Comments): Technical Committee shared that it would helpful for states to have insight into these facilities. \n\n6/14/2018: Complete. DoD data source has been added and configured in Production."]
[14,"BA-2578","Follow-up Needed","Medium","New Development","Data Sources","Incorporate new data sources (pending identification and prioritization by NSSP).  List may include:\n* NBS (notifiable diseases)\n* Relay Health (both ongoing and historic data)\n* Poison center data\n* EMS\n* Other data (as applicable) ","11/27/2018 (Technical Committee Comments):Recommendation to prioritize centralized repositories of information, such as poison center data, death data, pharmacy/OTC sales, and notifiable conditions. \n\n9/24/2018: Discussed LOE for adding LabCorp module.\n\n3/19/2018:Need NSSP discussion."]
[15,"BA-5295","Follow-Up Needed","Low","Enhancement","Data Sources","Add patient profile to the stat table, using underlying census (or other population count) data","11/27/2018 (Technical Committee Comments): Technical Committee will require more information related to where the population rates calculation will take place. \n\n6/14/2018:Share new enhancement request with JHU to determine LOE and priority of task."]
[16,"BA-5102","Open","High ","New Development","Data Sources","Add data access controls that support different types of aggregations of the data (e.g., state, region) and allow sharing of data with different partners without giving access to PHI","11/27/2018 (Technical Committee Comments): States often receive access requests to data from surrounding areas but those accessing the data do not require all details for every record. Requestors usually want to compare trends/demographics, etc. Requestors are given access to \"aggregate\" data. \n\n7/30/2018: Share new enhancement request with JHU to determine LOE and priority of task."]
[17,"BA-3752","Follow-Up Needed","Low","Enhancement","Data Visualization","Weather Station data overlay:\n1) ability to overlay multiple weather stations as separate lines on a graph (currently if you select multiple stations, it is aggregated into one line on the graph)\n2) ability to select more than one variable in the weather station data source to overlay within a query (e.g., min temp and max temp)","11/27/2018 (Technical Committee Comments): Technical Committee believes that objectives may be achieved with existing features (overlay and stratification).  Additional information will need to be provided.\n\n10/29/2018:NSSP to investigate the request (see associated JIRA ticket)\n\n6/14/2018:Clarification is needed regarding the ask and JHU's resolution.\n\n4/30/2018:1) This can be done with stratifications.  \n2) This can be done with overlays. "]
[18,"BA-4520","Complete","Medium","Bug Fix","Data Visualization","For the Facility Location data source, ensure hospital state and hospital HHS region layers in the maps are functional","Indicated as complete in email update on 9/10/2018."]
[19,"BA-3753","Follow-Up Needed","Low","Enhancement","Data Visualization","Data Visualization: Produce one graph that includes visit to hospitals in a specified region by non-regional visits by KS residents and non-KS visits","11/27/2018 (Technical Committee Comments):Additional information will need to be provided to Technical Committee. \n\n10/29/2018:NSSP to investigate the request (see associated JIRA ticket).\n\n6/14/2018:Follow up to confirm requirement."]
[20,"BA-5108","Open","Medium","Enhancement","Data Visualization","Add functionality to ESSENCE maps that allows users to view facility information by region or ZIP code. (Related to Issues 2 and 21)","11/27/2018 (Technical Committee Comments): Technical Committee would like to see facility location data aggregated to facility region rather than only individual facilities. ZIP code would be lower priority. \n\n7/30/2018: Share new enhancement request with JHU to determine LOE and priority of task."]
[21,"BA-5109","Open","Low","Enhancement","Data Visualization","Add functionality that adds greater flexibility when modifying dashboard geographies (Related to Issues 2 and 20)","11/27/2018 (Technical Committee Comments): It appears that dashboard geographies now filter based on either patient or facility region, depending on the datasource selected for the original query. It would be helpful to specify whether the user is filtering based on facility or patient region rather than automatically filtering based on datasource. \n\n7/30/2018: Share new enhancement request with JHU to determine LOE and priority of task."]
[22,"BA-5110","Open","Low","Enhancement","Data Visualization","Add additional time frames for map displays on MyESSENCE dashboards","11/27/2018 (Technical Committee Comments): It would be nice to look at data from 2 days before to view a complete and reasonably sized set of data. States would more often prefer to view county or ZIP code level data. \n\n7/30/2018: Share new enhancement request with JHU to determine LOE and priority of task."]
[23,"BA-5113","Pending Discussion/Feedback","Medium","Enhancement","Data Visualization","Add functionality that allows users to create a map of AQ monitor data and weather data (and add them to a dashboard) so that they can monitor for geographic areas of poor air quality or high heat in conjunction with respiratory illness or heat-related illness","11/27/2018 (Technical Committee Comments): It would be useful to view this information for a day or week with an option to overlay patient information.  \n\n10/29/2018:There is no way to add this functionality because the latitude/longitude for AQ monitor data is unknown. Weather station data that has this information would need to be found and be usable. If the Technical Committee deems this to be a high priority NSSP we can determine next steps and discuss alternatives.\n\n7/30/2018: Share new enhancement request with JHU to determine LOE and priority of task."]
[24,"BA-4519","Follow-Up Needed","Low","Enhancement","Performance","Increase performance while running detection job","11/27/2018 (Technical Committee Comments): The Technical Committee recommended a frequency of 1/day and recommended more training on myAlerts for the community. \n\n6/14/2018: Touch base with CDC regarding their follow up with identified users (users with abnormally long running queries).\n\n4/30/2018: Next Steps: \n1) Need to analyze MyAlerts query Log for slow queries.  \n2) Need to analyze MyAlerts for users that have many MyAlerts, but don't look at them.\n3) Touch base with CDC regarding their follow up with identified users (users with abnormally long running queries).\n\n3/19/2018: Currently, the detection job is on a longer schedule to allow for data to appear on the web front end quicker.  This is a standing topic - discussing performance enhancements to allow for posting to the web, detection, queries, and data processing."]
[25,"BA-4462","Complete","Medium","Enhancement","Performance","Review and assess Query Logs:\n* Assess if query logs supports need for national cube\n* Assess if there are additional indexes we can add that may help improve query performance\n* Assess how to best track ESSENCE activity for users (and potentially display that with all/some ESSENCE users)","11/27/2018 (Technical Committee Comments): More discussion needed. Consider tips on where/how we need to optimize based on frequent activities. \n\n7/30/2018: Additional logging included the following features:\n* Added more data queries into the query log (more places in the website for logging that weren’t there before). \n* On the detection side, started logging all the MyAlert queries. \nLooking forward could implement overarching monitoring system that monitors those logs to catch any concerning activities.\n\n6/14/2018:JHU added additional logging to allow for better usage analysis on 3/21. "]
[26,"BA-4463","N/A","N/A","Enhancement","Performance","Tokenize free text - could leveraging Rich's Term Generator speed up free text queries?","10/29/2018:This enhancement is no longer being pursued because of the issue identified on 7/30/2018.\n\n7/30/2018: Test hasn’t been performed yet. Problem is that in order to take advantage of that system, the way people query in ESSENCE would have to change (no more front-end wild cards). This may not work in ESSENCE.\n\n6/14/2018:Follow up with JHU regarding test results.\n\n4/30/2018: This would require users give up on pre-word wildcards.  This functionality can be tested to see how users would respond to such a query system before replacing the existing one."]
[27,"BA-4482","Open","Low","Enhancement","Performance","Discuss Option of Different Databases for ESSENCE Web; Data is being loaded into the Web DB at the same time users are querying against it, the performance of the db can be negatively impacted. Option to potentially have two databases for data loading and user queries (i.e., WebDB1 and WebDB2).","3/19/2018: Standing item to review/evaluate performance of web interface to determine if updates are needed in the future.  As of March 2018, this is not an issue for ESSENCE."]
[28,"BA-3708","Follow-Up Needed","High ","Enhancement","Query","Allow users to kill their own queries","12/12/2018: CDC will share more information with the Technical Committee related to prioritizing queries and the impact to performance. \n\n10/29/2018: JHU could not identify a resolution that wouldn't compromise security. The alternative would be to prioritize queries (See Issue 52).\n\n7/30/2018: Looked into resource management that pooled resource into appropriate sized groups but haven’t had a chance to look into if users can kill their own queries. Difficult for every user doesn’t get their own database ID. Would have to drop down username from query log."]
[29,"BA-3711","Open","High ","Enhancement","Query","Query Portal: add \"Calculated Death = C_Death\" as queriable field","10/29/2018:Straightforward addition to ESSENCE functionality once the value set is identified.  C_Death values can be mapped to \"Yes\" and \"NR\" (i.e., if C_Death is null, the web interface will display \"NR\").\n\n7/30/2018: JHU will double check data and circle back with CDC on naming conventions. Can be added on-the-fly in a view. Because C_Death values are Yes or No, NULL values won’t show up in stratification. Can get around this by using a view. A site recently did something similar where they looked if DischargeDiagnosis had a value in it and then compared users with that specific DischargeDiagnosis to all users with non-null DischargeDiagnosis."]
[30,"BA-3709","Open","Medium","Enhancement","Query","Query Portal: add \"Patient ID\" and \"Visit ID\" as text-queriable fields","11/27/2018 (Technical Committee Comments): Technical Committee shared that they can workaround the issue if  the pool of data is narrowed to less than 5K records and then filtered. \n\n6/14/2018:Follow up with JHU on estimate of when CDC can expect to have this resolved."]
[31,"BA-4491","Open","Low","Enhancement","Query","Query Portal: add \"Organization\" (from MFT) and \"Feed Name\" as queriable fields","11/27/2018 (Technical Committee Comments): Technical Committee shared that this issue is handled through facility naming conventions. Organization names are tagged onto the facility name to help group. \n\n6/14/2018: Follow up with JHU on estimate of when CDC can expect to have this resolved.\n\n3/19/2018: Parent_Organization (from the MFT) is not currently pushed to NCA_Hospitals table.  Would need JHU to add this field to facility table(s) in the system, then NSSP would update procedures to push the organization into ESSENCE. Feed_Name is populated in ESSENCE (from the Archive). "]
[32,"BA-4810","Follow-Up Needed","Low","Enhancement","Query","Query Portal:  Add additional free-text queriable fields for Diagnosis_Combo, Procedure Code / Procedure Combo","11/27/2018 (Technical Committee Comments): Procedure codes would be used more if they could be queried. \n\n5/18/2018: Diagnosis Combo added as free text queriable field on 3/21. Procedure code and Combo still need to be added."]
[33,"BA-5083","Open","Low","Enhancement","Query","Add additional functionality for Facility Type including:\n\n 1. An MFT facility list (like we have a patient class list) and/or indicators of associated facility types (like we have with the \"hasbeen\" flags). \n 2. Ability to query against facility_type_code/facility_type_description (as reported in the data)\n 3. Ability to query on the \"multiple facility types\" that may be represented in the MFT \n 4. Modify processing logic for last non-null/first non-null rules around facility_type_code/facility_type_description (as reported in the data)","11/27/2018 (Technical Committee Comments): Technical Committee would like to be able to query against values sent in data. MFT facility type is nice and clean because users control it, but they are unable to separate out some outpatient visit types because there is only 1 facility type associated with a facility that has primary, urgent, and specialty care. It was shared that users try to get these flags included in the data itself. Functionality 1,3, and 4 may not be needed. \n\n7/30/2018: Share new enhancement request with JHU to determine LOE and priority of task."]
[34,"BA-5089","Open","Medium",null,"Query","Add functionality to ESSENCE that allows users to expand a visit record to see other visits associated with that same PID","11/27/2018 (Technical Committee Comments): Technical Committee shared that they are often asked to look at a particular patient longitudinally. It would be nice to have a way to look at recurrent visits in mass. \n\n7/30/2018: Share new enhancement request with JHU to determine LOE and priority of task."]
[35,"BA-5098","Complete","High ","Enhancement","Query","Add functionality where users can download the data tables for overlay timeseries (in addition to the original timeseries) without creating a separate query","Indicated as complete in email update on 9/10/2018."]
[36,"BA-5101","Open","Medium","Enhancement","Query","Edit query functionality to allow some special characters (i.e., & ^ ')","11/27/2018 (Technical Committee Comments):Technical Committee mentioned current workarounds but would prefer to query directly. \n\n7/30/2018: Share new enhancement request with JHU to determine LOE and priority of task."]
[37,"BA-4811","Follow-Up Needed","Low","Enhancement","UI updates","Filter/select weather stations and AQ monitors within query portal (similar to facility selection for other data sources)","11/27/2018 (Technical Committee Comments): Technical Committee recommended switching to the \"Adder\" selection style. \n\n6/14/2018: Users can multiselect weather stations and AQ monitors, but there is no way to filter by state or use a string search."]
[38,"BA-4561","Complete","Medium","Enhancement","UI updates","Modify functionality of data details page display - freeze the header row of the table and/or freeze specified columns to make the display more user friendly","JHU fixed on 6/4/2018. Ticket Resolved."]
[39,"BA-2288","Follow-Up Needed","Medium","Enhancement","UI updates","Limit Adder/ Configuration Options based on User's Data Access Permissions / Modify how users create queries","11/27/2018 (Technical Committee Comments): It would be nice to have the facilities limited down to those that a user can access to avoid filtering down to state/county every time. This would be nice for county users that only have a subset of a state's facilities. \n\n6/14/2018: Follow up with JHU on estimate of when CDC can expect to have this issue resolved.\n\n3/19/2018:JHU is working on modifying the way users select data to include in queries; this should alleviate the identified issue."]
[40,"BA-3710","Complete","High ","Enhancement","UI updates","Add option to filter users when sharing a query","6/14/2018: Text search/filter functionality added. "]
[41,"BA-4515","Follow-Up Needed","High ","Bug Fix","UI updates","Name variables consistently within ESSENCE","11/27/2018 (Technical Committee Comments): It would help to have consistent names in the various tools. In some places it uses ChiefComplaintHistory and others it's Chief Complaint Updates.\n\n6/14/2018: On 6/4 JHU fixed label of Computed_Patient_Class_History Free Text to Calculated_Patient_Class_History Free Text. Example: When the data details Excel file is downloaded, the \"Facility Name\" column is renamed \"HospitalName\"."]
[42,"BA-2714","Follow-Up Needed","Low","Enhancement","UI updates","Add a \"Query Description\" text entry field for Query Manager to better identify queries","6/14/2018: Follow up to determine if this may already be supported by the \"View Description\" button on Query Manager."]
[43,"BA-5090","Follow-Up Needed","Low","Enhancement","UI updates","Add option to filter users by jurisdiction when sharing MyESSENCE tabs","9/10/2018: Updated on Query Manager. JHU will apply the same update to MyESSENCE in near future."]
[44,"BA-5093","Open","Medium","Enhancement","UI updates","Add functionality to ESSENCE that allows users to view a list of people with whom they've shared MyESSENCE tabs (and whether they were managed or not)","7/30/2018: Share new enhancement request with JHU to determine LOE and priority of task."]
[45,"BA-5094","Complete","Medium","Enhancement","UI updates","Add functionality for easier editing of saved queries and widgets on MyESSENCE","Indicated as complete in email update on 9/10/2018."]
[46,"BA-5103","Open",null,"Enhancement","UI updates","Add something on the data details page that says \"X records pulled\";This could be something that prints out onto the webpage or something like Excel where if you highlight rows/cells and it tells you the count at the bottom of the screen.","7/30/2018:Share new enhancement request with JHU to determine LOE and priority of task."]
[47,"BA-5106","Open","Medium","Enhancement","UI updates","Change the way that MyESSENCE tabs display so that instead of a lateral scroll they stack in rows","11/27/2018 (Technical Committee Comments): Consider the ability to group tabs and stack them. Consider the ability to select tabs from drop-down. \n\n7/30/2018: Share new enhancement request with JHU to determine LOE and priority of task."]
[48,"BA-5107","Open","Medium","Enhancement","UI updates","Investigate Column Width/Height Improvements on Data Details Table","11/27/2018 (Technical Committee Comments): Sometimes a record will take up almost the entire data details viewer window and appear as if it's blank because one field is particularly long. The wide fields are not helpful. The ability to apply text wrap and adjust columns width may help. \n\n7/30/2018:Share new enhancement request with JHU to determine LOE and priority of task."]
[49,"BA-5112","Open","Low","Enhancement","UI updates","Modify the sizing (or sizing options) for MyESSENCE widgets to make them more consistent and visually appealing","7/30/2018: Share new enhancement request with JHU to determine LOE and priority of task."]
[50,"BA-2287","Open",null,"Enhancement","UI updates","Add ability to share specific MyAlerts in MyEssence tabs through the UI","12/12/2018: Further discussion required with Technical Committee. \n\n9/10/2018: Share new enhancement request with JHU to determine LOE and priority of task."]
[51,"BA-5294","Open","High ","Enhancement","UI updates","Add \"has been\" filters to the CCQVT so we can limit the CCQVT results to ED only, etc","11/27/2018 (Technical Committee Comments): This enhancement will be use for those that rely on CCQVT for query building/validation. It was recommended to consider facility type as well. "]
[52,"BA-5266","Open","Medium","Enhancement","Performance","To better track/control system interconnections, JHU should implement separate user IDs for different system functions.  This could also be leveraged to prioritize user and/or system queries and optimize web application performance.","11/27/2018 (Technical Committee Comments): Further clarification will need to be provided to Technical Committee. "]
[53,"BA-4902","Open","High ","Enhancement","Performance","Investigate if partitions can be used to speed up data processing (by site, by year, etc.)"]
[54,"BA-5084","Open","Medium","Enhancement","UI updates","Add ability to view current patient volume","11/27/2018 (Technical Committee Comments): Technical Committee State is testing this flu season to see what measures work well for monitoring hospital census, length of stay stats, and what are the best indicators for how overrun a hospital might be. This could be helpful, but might be premature to know what the best measure is."]
[55,"BA-5169","Open","Low","Enhancement","Data Quality","Define ESSENCE Data Quality reference table updates","11/27/2018 (Technical Committee Comments): More details will need to be provided related to what DQ tools are needed within ESSENCE in addition to other tools. "]
[56,null,"Open","Medium",null,null,"“Star” fields are currently not ingested into ESSENCE.                        Should ESSENCE ingestion include  “Star” fields? If so, all fields or select fields (ex: str_birth_date_time, str_admit_date_time such that you can see the value actually reported which may not have successfully converted to the “permanent” field (ex:  birth_date_time, admit_date_time).","11/27/2018 (Technical Committee Comments):Technical Committee would like to see what was originally sent both for evaluating and analyzing data. Data is currently not converted to actual dates and appear missing in the numeric Birth_Date_Time field. \n\n10/29/2018:Share new enhancement request with JHU to determine LOE and priority of task."]
[57,null,"Open",null,"Bug Fix","Data Processing","Most fields in ESSENCE have a rule that the last value received is kept, even if it is NULL when a previous value was provided. The assumption was that each message would build upon a previous message and if data was missing, it was likely a valid correction rather than just missing information. This assumption was based on the old-school flat files that used to be sent to ESSENCE. In reality, HL7 ADT update messages may more often than not, be incomplete such that relevant/valid information gets replaced with blank. Perhaps we should revisit these business rules again and whether they are applicable for the way that data is transmitted.","Similar to Data Flow Enhancement Issue 14"]
[58,"BA-5404","Open",null,"Enhancement","UI updates","It'd be great if there was a pop-up feature to grab the API URL for time-series and/or data details from widgets in a myESSENCE dashboard. That way if you wanted to grab a bunch (e.g., comparing queries) you don't have to open each one up in a new window, wait for it to load and then get the API URL. "]
[59,"BA-5403","Open",null,"Enhancement",null,"If you create a timeseries and stratify it by some factor, it would be great to be able to grab the data table for those stratifications in an API URL. You can essentially accomplish it by doing a data table, but you have to set out to do that from the beginning."]
[60,"BA-5402","Open",null,"Enhancement",null,"Perhaps there could be a managed/unmanaged approach to myAlerts. For example, user A can create and share unmanaged myAlerts with user B and delete from user A's account without user B losing the alerts. User A can create managed myAlerts as well where user A does maintain control over the alert. This should also be done for queries shared in Query Manager if it is not already done."]

{"sheet":"AMC Enhancements","index":3,"n_rows":94,"n_cols":9,"rows_kept":94,"cut":false,"hidden":false,"merged":[[0,0,0,8],[1,0,1,1],[1,2,1,3],[1,4,1,7]]}
["AMC Enhancements"]
["Issue #",null,"Status and Priority ",null,"Enhancement Summary",null,null,null,"Implementation Status"]
["Issue #","JIRA Ticket","Status","Priority","Issue Type","Functional Component","Enhancement Description","Notes","Deployed in Production?"]
[1,"BA-5152, \nBA-5196","Complete","High","New Development","Application Access","Once SAS is implemented there needs to be a way to identify users that will receive access and need accounts created. Add SAS User identification checkbox to the user profile page to notify NSSP technical team to create a SAS account for users. ",null,"Yes\n12/3/2018"]
[{"$f":"A4+1","v":2},"BA-5262","Complete","High ","New Development","Application Access","Add SAS Studio and description to AMC homepage in NSSP Application textbox that links to SAS URL.",null,"Yes\n12/3/2018"]
[{"$f":"A5+1","v":3},"BA-5151,\nBA-5219","In Progress","High","Bug Fix","MFT Module","A defect currently exists for Vendor_Effective_Date in which the information stored for each facility is incorrect due to the structure of the database. Update Vendor Effective Date to meet requirements and capture the date that a primary facility started using a specified EHR vendor (Vendor Name on the MFT facility information page)."]
[4,"BA-4865","In Progress","High","Enhancement","N/A (View)","Create view for vendor history that summarizes all vendors that have been used for a specific facility over time (Related to/part of Issue #3)."]
[5,"BA-4162","Open","High","New Development","Log-in","Minimum password requirements have changed for non-privileged users (security requirement). Update password requirements and corresponding email for site administrators and users."]
[6,"BA-5176","Open","High","New Development","Log-in","Minimum password requirements have changed for privileged users (security requirement). Update password requirements and corresponding email for super administrators."]
[7,"BA-5198,\nBA-5154","Open","High","Enhancement","(To be created)","New security requirements require that all existing user information be updated to include Foreign National and Contractor identification. To accomplish this, develop a \"mass update\" screen that allows Site Administrators to provide this information or inactivate current users should be developed. This screen can then be repurposed to meet the need for a yearly audit of users. Create mass update screen (Yearly Audit 2019 tab) to update user profiles. "]
[8,"BA-5018,\nBA-5197","Open","High","New Development","Manage Users ","New security requirements require that users indicate whether they are a Foreign National and/or a Contractor. Add Foreign National and Contractor identification radio buttons to User Profile.","Technical Committee Comments 11/27/2018: The Technical Committee has concerns about pushback when asking users if they are Foreign Nationals.\n\nHowever, this is a security requirement we must implement."]
[9,"BA-5148","Open","High","Bug Fix","MFT Module","Onboarding and ADM Comments fields are cleared if a facility is approved (no longer under review). Site, Onboarding, and ADM Comments fields should function the same: populate existing values, overwrite with current user inputs, have same lengths to preserve the comments tied to a facility over time, and allow each participating stakeholder to provide comments regardless of review status.","Technical Committee Comments 11/27/2018: It was noted that the history of the comments should be preserved. \n\nThis enhancement is designed so that the comments field is fully editable to the appropriate privilege levels. (I.e., Comments can be added and the previous comments can remain, or old comments can be overwritten if necessary.) Still, the history of the comments will be preserved in the history tables. "]
[10,"BA-5156","In Progress","High","Enhancement","N/A (View)","MFT displays the change made by the site administrator that is pending review.\n\nFor example: A facility changes from Onboarding to Active. MFT Facility_Status = Active when, in reality, Facility_Status = Onboarding (in data processing tables and ESSENCE) until approved by OB and ADM. \n\nThis will happen with all review reasons (i.e., the MFT will display the value input by user, but the information is not updated on the backend until OB and ADM approve). There is no easy way to see what values were previously in the MFT facility form prior to changes made by site to compare \"last complete\" record to records that are pending facility review.\n\nA view of a given facility's \"last complete\" record needs to be made available"]
[11,"BA-5149","Open","High","Bug Fix","MFT Module","Fix/update vendor dropdown and associated fields\n1) Update dropdown to include \"Unknown\"\n2) On Vendor Software, after you add a \"specify other\" Vendor Name or Software and save, it displays as expected but the information that was typed shows up in the drop-down list. \n3) Specify Vendor Software and Specify Vendor Name, if left blank, auto populates with 0. If Specify Vendor Software and Specify Vendor Name are left blank, save and display as blank (null), no \"0\".","3) Retested in TEST on 10/01/2018: Specify fields are required when Other is selected and Facility Status= OB. When Other is selected and Facility Status= Planned, Specify fields can be left empty, but Other did not save. \nNeed to redefine vendor drop-down requirements."]
[12,"BA-5175","Open","High","Enhancement","MFT Module","A site can only add one facility at a time to the MFT module. Add batch upload capability for MFT facility forms for primary facilities (add only for now)."]
[13,"BA-5153","Open","High","Bug Fix","MFT Module","Not all facility review triggers are triggered if a facility status is changed from Planned to Onboarding (and then Active), thus not all necessary fields are indicated to be checked by OB and ADM. Correct facility review triggers and workflow. Review/redesign facility review workflow to perform validation checks on each save."]
[14,"BA-5174","Complete","High","Bug Fix","MFT Module","Review Reasons dropdown on the MFT Review tab are not listed (contain Facility Status options). Update Review Reasons drop-down options.",null,"Yes\n12/3/2018"]
[15,"BA-5145","Complete","High","Bug Fix","MFT Module","Site administrators are able to approve their own changes within the MFT facility form by clicking the OB and ADM approval radio buttons. Radio buttons to approve changes to facility form should be un-editable by site administrators at all times. Site administrators should not be able to approve their own changes. Fix approval radio button functionality.",null,"Yes\n12/3/2018"]
[16,"BA-5146","Pending Discussion/Feedback","High","Bug Fix","MFT Module","Depending on a facility's current status, it should only have specific options to change to (Example: If a facility status is Active, the only possible option to change to should be Inactive). Update facility status drop-down options to adjust based off of current status value.","Technical Committee Comments 11/27/2018: Some people are putting a facility back in Onboarding status or Planned if they change EHRs and go offline temporarily or need to be revalidated. In this case, Inactive does not seem the appropriate status to change to as that may indicate a facility permanently went offline or at least is not anticipated to come back online (e.g., closed down). \n\nFurther discussion needs to be had to determine if the above workflow is desired or if it desired that a facility go from Active to Inactive back to Onboarding in the case that they change EHRs or need to be revalidated.","Yes\n12/3/2018"]
[17,"BA-5147","Complete","High","Bug Fix","MFT Module","ESSENCE only allows for latitude values between -90 and 90 and longitude values between -180 and 180. ESSENCE uses 0 for unknown values. Currently MFT facility form accepts entries of 0 and 0 but is not saving and displaying. Add latitude/longitude validation (limited to between -90 and 90/-180 and 180). Additionally, allow for, save, and display entries of 0 for latitude and longitude.",null,"Yes\n12/3/2018"]
[18,"BA-5137","Complete","High","Bug Fix","MFT Module","Clicking the filter button on the MFT and MFT review tabs yields no results. Filters correctly as filter choices are typed in or selected from dropdowns but once filter button is clicked, no results are yielded. Fix MFT tab filter button functionality.","Technical Committee Comments 11/27/2018: There is also an issue where hitting \"Enter\" to submit the filter criteria opens a new blank facility record instead of applying the filter criteria to the list of facilities.","Yes\n12/3/2018"]
[19,null,"Open","High ","Bug Fix","MFT Module","The downloadable reports (on the MFT tab and the MFT Review tab) do not include Record_Status (i.e., Pending OB Approval, Pending ADM Approval, Pending Site Review, or Complete). Add Record_Status column to MFT downloadable reports."]
[20,"BA-5322","Open","Medium","Enhancement","MFT Module","Once an associated facility is added, it cannot be changed. Add ability to edit associated facilities.","Given that the associated facility information may directly affect the crosswalk, the initial MFT release was limited so that users could only add associated facilities as they came up to speed on the new terminology. The onboarding team can make direct modifications to the underlying data upon request."]
[21,"BA-5309","Open","Low","Bug Fix","MFT Module","If a facility has multiple Review Reasons, the Review Reasons dropdown on the MFT Review tab does not function properly if the second, third, etc. Review Reason is selected to be filtered. Update Review Reasons drop-down functionality."]
[22,"BA-5144","Open","High","Bug Fix","MFT Module","Crosswalk insert duplicate constraint: Must NOT have duplicate inserts based on Primary FacilityID_UUID, Associated FacilityID_UUID, Input Facility ID, Output Facility ID, AND C BioSense_Facility ID. Review and update crosswalk insert procedure (specifically duplicate inserts and associated facility patient class)."]
[23,"BA-5150","In Progress","High","Enhancement","MFT Module","Onboarding and ADM Comments are only editable if a facility is under review. Onboarding and ADM Comment fields must be made usable independently from the facility review workflow. Should only be editable by Super administrators, editable for ALL record_status values, and can be edited even if OB_Approval and ADM_Approval are null.","Pass in TEST: Allows for editing but comments do not save (related to enhancement 7)"]
[24,"BA-5255","Complete","High","Bug Fix","MFT Module","URL for latitude/longitude lookup takes to a webpage that no longer exists/cannot be reached. Update URL for latitude/longitude lookup.",null,"Yes\n12/3/2018"]
[25,null,"Open","Medium","Enhancement","MFT Module","Add the ability to batch add associated facilities to the MFT. "]
[26,null,"Open","Medium","Enhancement","MFT Module","There is no indicator for an administrator to know if his/her changes are approved (administrator would have to manually check each facility change made). Update review workflow to send an email to site administrators indicating whether their addition/edit was approved (may need to include an opt-out feature)."]
[27,null,"Open","Medium","Enhancement",null,"Currently AMC writes to ESSENCE by inserting \"values\" to a location specified in the code. Update the stored procedure to have the location AMC writes to ESSENCE in a separate piece of code (or configuration table) so that it is easier to update/manipulate in the future."]
[28,null,"Open","Low","Enhancement","MFT Module","Currently there are no trigger warnings in the UI but additional review is required for certain fields. Add warning or pop up related to missing AHA IDs and other review reasons. "]
[29,null,"Open","Low","Enhancement","MFT Module","Besides the Site, Onboarding, and ADM comment fields there is no option to capture comments specific to AHA IDs missing. Add ability to capture comments for missing AHA IDs. Include checkbox so Onboarding can verify that an AHA does not exist for a facility.","Technical Committee Comments 11/27/2018: Site administrator can note that the AHA ID is missing or does not exist in the general comments field"]
[30,null,"Open","Low","Enhancement","MFT Module","Users can select a planned date in the past. Warn user if they select a planned date in the past (or restrict from choosing past date)."]
[31,null,"Open","Low","Bug Fix","MFT Module","When reviewing a facility, the highlighted tab at the top is \"MFT\". When reviewing a facility, the highlighted tab at the top should be “MFT Review,” not “MFT.” This enhancement only impacts super administrators"]
[32,"BA-4866","Open","Low","Enhancement","(To be created)","Add contacts tab containing site contact information (site administrators, facility contacts, and feed contacts). Tabs would capture Facility Phone number and other helpful identifying information. ","Technical Committee Comments 11/27/2018: If there are not scenarios where NSSP is in direct contact with a facility, it is unclear how facility contact information is needed. This could be helpful for site administrators who need to keep track of such contact information. Regardless, this should be made optional. "]
[33,null,"Open","Low","Enhancement","MFT Module","City, state, and ZIP code are not displayed for Associated Facilities. Capture, save, and display city, state, and ZIP code for Associated Facilities."]
[34,null,"Open","Low","Enhancement","MFT Module","A site can add a facility that is not within the site. Add validation for the state field. (Suggestion: consider simple check/warning to user that state chosen was not same as site's designated state). ","Technical Committee Comments 11/27/2018: There should be a warning (in case of data entry error), but a site should be able to add a facility that is not within the site since some sites cross jurisdictional boundaries.  Also, sites aren't always states so this wouldn't capture all scenarios."]
[35,null,"Open","Low","Enhancement","MFT Module","There is no validation on the NPI field. Add validation for the NPI field (it should always be a 10-digit character)."]
[36,null,"Open","Low","Enhancement","MFT Module","The downloaded report is of all facilities within the site. Downloaded report should be filtered by the fields that are already filtered on the MFT tab.","Technical Committee Comments 11/27/2018: The Technical Committee notes it is easy to filter after downloading and has concerns that people may not realize they have the list filtered when they download."]
[37,null,"Open","Medium","Enhancement","MFT Module","When scrolling down the MFT (and MFT Review) the headers do not lock in place, so user cannot tell what row the items are corresponding to. Headers on MFT tab and MFT Review tab (e.g., View/Edit, Site and Review Status) need to lock in place when scrolling through the facilities."]
[38,null,"Open","Medium","Bug Fix","MFT Module","Last modified time and user stamps not working when an associated facility is added (under \"Version Control\"); relates to time stamps under \"Associated Facility Information\" also not functioning properly. Fix last modified time and user stamps for the addition of associated facilities."]
[39,null,"Open","Low","Enhancement","MFT Module","Enable crosswalk auditing and tracking to preserve a record of who performs updates and when the operational crosswalk is updated."]
[40,null,"Open","Low","Enhancement","MFT Module","Associated Facilities show up in the MFT, but their “Facility Display Name” does not include the “Site-“ abbreviation. Example:\na. Primary  facility with name Mercy Healthcare = NSSP-Mercy Healthcare\nb. Associated Facilities = Mercy Healthcare  (without NSSP-). \nFormat associated facility displayed name to be like primary facility display name."]
[41,null,"Open","Medium","Bug Fix","MFT Module","If OB and ADM reject a facility, site cannot resubmit changes (site must click \"cancel change\" button to remove \"Pending Site Review\" status). Fix review workflow."]
[42,null,"Open","Medium","Enhancement","MFT Module","Add operational crosswalk view to Facility Form User Interface to allow all crosswalk entries tied to a particular Primary Facility to be displayed for the Site Administrator."]
[43,null,"Open","Medium","Enhancement","MFT Module","If user wants to edit multiple facilities, he/she must edit each one individually. Add batch upload capability for editing of MFT facility forms."]
[44,null,"Open","Medium","Enhancement","Manage Users","Consider options to prompt Site Administrator review of existing accounts (e.g., notify Site Administrator if accounts have not been used for a certain period of time, if account email values are changed to a \"non site\" value [e.g., for DoD, if the email address changes from @mil to @gmail, alert DoD Site Admin])."]
[45,"BA-5180","Open","Low","Bug Fix","User Groups","Currently Operation Access site users must be manually added to the AD group for CDC NSSP Read Only. Operational Access Site Users must automatically be added to AD group for CDC NSSP Read Only."]
[46,"BA-5111, \nBA-5139","Open","Medium","Enhancement","Manage Users","Define and create new privilege level(s) for AMC access.\n• Create separate access to MFT Module to non-Site Administrators as designated by the Site Administrator. (Consider making MFT Module access similar to other access options under the individual user's profile page for Site Administrators in the AMC.)\n• Create users that only have permission to manage the MFT facility information, but cannot create users or data access rules. ","Technical Committee Comments 11/27/2018: Whether there is any information site administrators would not want to make available to the non-site administrators (e.g., contact info) should also be considered."]
[47,"BA-5167","Open","Low","Enhancement","Manage Users","Add the ability to change site affiliation within AMC/AD/ESSENCE."]
[48,"BA-4899","Open","Low","Enhancement","N/A","\"AMC Hourly Maintenance\" stored procedure is slow. Update \"AMC Hourly Maintenance\" stored procedure to perform more efficiently."]
[49,"BA-4863","Open","Medium","Enhancement","N/A","If user encounters error in the AMC, the only way NSSP will know is if the user reports it. NSSP then has to reverse engineer the recreation of the error. Create stored procedure in AMC API to allow Java to log errors to the database."]
[50,"BA-4786","Open","Low","Enhancement","Manage Users","Reset Password and Unlock Accounts (from user info page) workflow is slow. Improve Reset Password and Unlock Accounts (from user info page) workflow to increase speed."]
[51,"BA-4690","Open","Low","Enhancement","Manage Users","Currently, if a site administrator (site A) adds a user to a user group that has access to another site's data (site B), that user will have access to site B's data. Site administrator (site A) should have the ability to add user to user group and that user should be able to see all of site A's data within the group but not site B's data. Allow for \"private\" users within a site. (\"Private\" users are users that only site administrators for that site can see and control data access.)","Technical Committee Comments 11/27/2018: The Technical Committee would like more clarification on \"private users.\"\n\nEssentially, private users will have limited data access controlled by the site administrator. This makes it easier for the site administrator to add this user to existing data access rules and not have to create specific more restricted rules. These users will also not be visible to other sites. "]
[52,"BA-4617","Open ","Low","Enhancement","N/A","Testing can be tedious and there is room for human error. Automate regression testing."]
[53,"BA-4588","Open","Low","Enhancement","N/A","Review AMC Java code for all pages to determine opportunities for enhancement and/or streamlining page functionality."]
[54,"BA-4526","Open","Low","Enhancement","Log-in","There is currently a workaround in place for users with PIV CAC cards. Develop and implement a permanent solution for PIV CAC cardholders with the same functionality as PIV cardholders."]
[55,"BA-4432","Open","Low","Enhancement","N/A","Review AMC code base to identify additional stored procedure modifications to increase performance. "]
[56,"BA-4219","Open","Low","Enhancement","Data Access","Example 1: Creating a new rule, site administrator selects Joe, Bob, and Steve. Site administrator is not shown a summary of selected users before moving on to the next page. Desired: Display selected user table while still on Select Users screen. \nExample 2: Editing an existing rule, site administrator removes Joe but adds Jim and Tim. Site administrator is not shown a summary of selected users before moving on (user has to click \"next\" then \"back\" to review users). Desired: Display selected users table while still on Select Users screen within the Data Access series of screens; the Select Users page should continually display a table of selected users. "]
[57,"BA-4218","Open","Low","Bug Fix","Data Access","Clicking \"X\" to delete a user from a rule should not automatically remove user access until the \"Save/Submit\" button is clicked on the \"Selected Users\" or \"Review & Save\" page. Currently, clicking \"X\" automatically removes user access immediately (no need to click save).\nWhen editing users in a rule, do NOT remove user access until/unless the Site Admin clicks \"Save/Submit.\"\nIf all users are removed from a rule, that rule is set to draft status. The error message does not indicate that this will happen. Error message should read \"At least one user or user group is required. This rule status will be set to \"Draft\" until users are selected.\" \nWhen editing users in a rule, update workflow and error message when no users are selected."]
[58,"BA-4217","Open","Low","Enhancement","Data Access","Users should be able to edit selected data in an existing line of data access rule (i.e., do not delete, but directly modify the facilities/counties/states involved in a record for data access). "]
[59,"BA-4141","Open","Low","Enhancement","Reports","The AMC Reports tab that shows users access also includes Inactive Users\n1. Add a filter option for user status\n2. Initial data displayed should include only users with status = active, new (do not display status = inactive)\n3. The download button should include ALL users in the site selected regardless of status."]
[60,"BA-4081","Open","Low","Enhancement","Data Access","Data Access tab should have an option to generate/download a report of all the data access rules (and associated users) for a particular site. The report should include the data source (with details or aggregate only) and all the users under that rule."]
[61,"BA-4069","Open","Low","Enhancement","Manage Users","If a user account with PIV enabled in AMC is marked as \"inactive,\" remove that user's x509 information from ESSENCE and mark the account as inactive. "]
[62,"BA-4064","Open","Medium","New Development","Data Access","Update Data Access Rules UI based on ESSENCE 1.21. ","Requirements gathering in January 2019.\n\nTechnical Committee Comments 11/27/2018: The Technical Committee would like more clarification on this.\n\nAs of now, the details on this are pending JHU development. As requirements start to be gathered in early 2019, more information will be available."]
[63,"BA-3890","Open","Low","Bug Fix","Manage Users","Currently, if a user forgets his/her password and requests a password reset through the AMC or if a user is forced to reset his/her password, the user 'status' value is set to \"NEW\". Ideally, the user status value would display \"Password Reset Requested\" (confirm wording).\nUpdate user status values when user is in \"password reset/forgot password\" status \n1. Determine the appropriate status values to display\n2. Update code to assign appropriate status values\n3. Update user interface, if necessary, to display correct status values (e.g., filter options and display containing the new values)."]
[64,"BA-3590","Open","Low","Enhancement","Log-in","When a user is logged into the AMC and the site is left idle for about 30 minutes:\n• For PIV Users the system forces user to renter PIN for PIV card but takes the user back to the account table choice for user to pick which account it wants to enter into. Desired Flow: The system forces user to renter PIN for PIV card; upon entering correct PIN user should be taken back to the AMC main page of the account that was previously timed out\n• For non - PIV Users the system forces the user to log back in. User should be directed to the AMC Home Page on log-in.\nUpdate current flow for idle PIV and non-PIV users."]
[65,"BA-3583","Open","Low","Bug Fix","Data Access","AMC does not delete rules with rule status = delete. Replace AMC inline SQL call to make a Rule marked for deletion to be updated to use stored procedure 'AMC_ESSENCE_removeRule'. The stored procedure 'AMC_ESSENCE_removeRule' will also accept the userID, that needs to the userID of the logged in AMC User. "]
[66,"BA-3532","Open","Low","Enhancement","N/A","Add a column to the site profile table that captures and stores the active directory group name for the site. The AMC will use this column to figure out what Active Directory Group the users land in."]
[{"$f":"A69+1","v":67},"BA-3440","Open","Low","Enhancement","Manage Users","Alert Site Admins if an email is already in use and/or user exists in another site.  Once an email address is typed in, system should generate a message to the Admin if the email address already exists in the system."]
[68,"BA-3381","Open","Low","Enhancement","Data Access","Notify site administrators (for user groups and access rules) when: \n• Any of site administrator’s users are added to another site’s user group\n• Any of site administrator's user groups is used for another site’s data access rule. "]
[69,"BA-3380","Open","Low","Enhancement","User Groups","Site administrator should be able to add a user group to one or many of my existing rules when he/she creates the user group."]
[70,"BA-3218","Open","Low","Enhancement","Data Access","Write fewer rows to ESSENCE (eliminate duplicates, multiples, and unnecessary data)."]
[71,"BA-3217","Open","Low","Enhancement","Data Access","There is a bug in the AMC database in which a DELETE from User_Profile will fail if the User_ID exists in a row in ESSENCE_Rule_User. This delete should cascade, in effect, deleting the user from the data-access rule when their User_Profile record is deleted (i.e., if user is inactive, he/she must be removed from user access rules)."]
[72,"BA-2826","Open","Low","Enhancement","Manage Users ","On the Manage Users tab in AMC, create a free text filter that allows users to filter by Organization."]
[73,"BA-2825","Open","Low","Enhancement","Data Access","When creating a rule on the first page of creating a data access rule (Describe Rule) the user should be prompted (asked) if they would like to enable a time limitation on a particular rule. On the Data Access Page, there should incorporate some time options for Site Administrators/Users."]
[74,"BA-2821","Open","Low","Enhancement","N/A ","Track the log in and out dates and times for all users in order to create a User Statistics Monthly Summary Report."]
[75,"BA-2744","Open","Low","Bug Fix","Data Access","When an AMC Rule Status is set to delete, the rule should be deleted from the AMC database. The log/audit table should record that the rule existed at one point but was dropped. Update Data Access rule deletion workflow. "]
[76,null,"Open","Low","Enhancement","Error Messages","If a user experiences an issue in the AMC, the error message does not clearly specify what the error was in most cases. The message will state something like \"An error occurred, please try again.\" Update the error messages to specify what issue the user is encountering."]
[77,null,"Open",null,"Enhancement",null,"While the MFT displays Active, the data under the hood (in the operational crosswalk and data that is pushed to ESSENCE) does not update until a facility is approved.  This may lead a user to think he/she is ready to send data to Production, but if sent, the data would route to Exceptions. A note/popup of some sort should be added when a user is in the tail end of validation, and is now requested a status change from Onboarding to Active. ","Clarify \"note/popup\" content"]
[78,null,"Open",null,"Enhancement","MFT Module","The “MFT Review” tab displays a list of sites/facilities in various review status states.  In an effort to assist with supporting the Onboarding Prioritization, it would be helpful to have the following updates made:\n• Add Facility Type\n• Add pertinent dates (to be discussed) to help determine “when” something was requested;  Potential ideas for “date markers” include the following\n     o Date user entered a facility status of Onboarding\n     o Date OB approval granted (and status changed to pending ADM approval)\n     o Date ADM approval granted\n     o Date user requested a facility status change to Active\n     o Date approved as Active","Need to narrow down critical display values from the suggestions provided; what would be most beneficial to the OB and/or ADM team without making the view too big?"]
[79,null,"Open",null,"Enhancement","MFT Module","An Active primary facility has been sending Production data (hypothetically, for some time); new associated facilities are identified; the site/NSSP wants to test the data first before allowing the data in as Active, and in Production. Currently, the user cannot add associated facilities with a different facility status from the primary. An SOP needs to be considered on how to handle this situation or potentially facilitate the ability (within the MFT) to test this data before sending to Production. ","Possible SOP approach:\n1) Add the “new associated facility” as a Primary facility in Onboarding status (separate from the Primary facility that the new facility is really associated with)\n2) Test/validate\n3) Once cleared, delete the independent Primary facility entry and add the facility as an Associated Facility under the true Primary Facility"]
[80,"BA-5409","Open",null,"Enhancement","Manage Users","When a new user is created in the AMC, that workflow is completely separate from assigning rights to data. There are cases where site administrators have created a user account, but then forgot to add the new users to any data access rules (or create one for them). The user will either notify the site administrator that he/she cannot see any data or may not realize that there is even an issue (being new, he/she may not know what to expect to see.) A prompt should be added to remind site administrators to create data access rules when they create a new user. Alternatively, the addition of a new user and addition of user to data access rules workflows should somehow be better linked if possible."]
[81,"BA-5408","Open",null,"Enhancement","Data Access","The creation of data access is still confusing to some site administrators. ESSENCE originally had a feature to allow system administrators the ability to log in as another user. It was super helpful to check that granting data access was done correctly. Site administrators should be able to test out a user account so the site administrators can verify that they correctly granted the user access."]
[82,"BA-5407","Open",null,"Enhancement","MFT Module","The system only tracks the last person to modify a facility's record. Site administrators cannot see the history of modifications made/submitted by the site versus those done by the NSSP/site administrators. It would be helpful to have more tracking on changes made to a facility.","This information can be obtained and shared by reaching out to site administrators."]
[83,"BA-5406","Open",null,"Enhancement","Data Access","There have been cases where a site administrator has created a new data access rule, added users, and saved it but not realized it was saved as a draft and not actually implemented. Improve the data access workflow to potentially add a prompt or reminder so that site administrators don't accidentally save rules as drafts by mistake."]
[84,"BA-5405","Open",null,"Enhancement",null,"There are several ideas around collecting and provisioning metadata. \n(1) There is the idea of having a sense of what site admins are seeing in the national picture data (e.g., What jurisdictions are contributing? Are there any issues viewers should know about?). \n(2) Locally, site admins are routinely wrestling with how to document \"information\" about a facility and/or its data and how to share pertinent information with data users so that they can use the data in an informed manner. \n(3) Site admins want to document which fields are sent/not sent by each facility. (This information is included in the DQ completeness reports, but it would be helpful to have this more integrated with other NSSP tools.) Site admins also want to be able to document facility/data oddities that they may be aware of and need to take consideration of (e.g., fields X,Y,Z get sent after discharge, CC completeness is known to be low, obstetric visits are missing diagnoses, facility X sends observation patients as inpatient). Site admins also want to document data anomalies that will not be corrected and that will persist forever in the data (e.g., outpatient clinic data was filtered out of the data starting on 1/1/17, dropping total visit counts, or data feed dropped-out on these dates, or on this date facility A switched to a new EHR). It would be helpful if this information could be provisioned through NSSP tools and if there could be a way to collect/enter that information in a user-friendly way. \n(4) Site administrators also struggle with how to document things that apply at the organizational-level and apply to all facilities in an organization (without it being super cumbersome to enter the information). This should also be filterable by facility, organization, date range, or issue type.","For idea (4), some site administrators have created an Excel spreadsheet that they can post on their local SP site to share with users and update/filter as needed. It would be helpful if something like that was integrated directly with the tools they use everyday and was accessible alongside the data. Otherwise, the spreadsheet is sometimes forgotten or not maintained."]
[85,"BA-5321","Open",null,"Enhancement","MFT Module","It would be useful to allow a read only view of the MFT via the AMC for local users who are not the designated administrator."]
[86,"BA-5445, \nBA-5446","In Progress","High ","Enhancement","Application Access","The \"download user\" report does not include information on if users have access to Rstudio, SAS, and/or Adminer/Datamart. Update \"download user\" report to include this information. "]
[87,"BA-5451","In Progress","High ","New Development","Application Access","Update the SAS User Setup email that is sent to the NSSP IT team to include the user's email address. "]
[88,"BA-5448","In Progress","High ",null,null,"Create a way to capture when the AMC Rule insert to ESSENCE procedure does not fully complete (e.g., AMC inserts rule information but ESSENCE conversion procedure does not successfully complete)."]
[89,"BA-5449","In Progress","High ","Bug Fix","New Development","There is no Staging environment available for the development team to properly test deployed code. (The Staging environment that currently exists has suppressed MFT functionality.) Having a testable Staging environment is critical to development. Stand up a Staging environment that can be used to test deployed code but is only accessible to development team and does not affect the Staging environment that site and super administrators use."]
[90,"BA-5515","Open","Medium","Bug Fix","My Profile","\"My Profile\" and the user profile on the \"Manage Users\" tab need to be streamlined so the pages remain in sync. "]
[91,"BA-5452","In Progress","High ","Bug Fix","My Profile","The SAS checkbox is not available in “My Profile” under “My Info” on the homepage (i.e., users cannot see if they’ve been granted access to SAS). Users can still be granted access to SAS by site (or super) administrators since this is done via the “Manage Users” tab. (The SAS checkbox is available and editable by site and super administrators only via the “Manage Users” tab by clicking “View/Edit” for a user.) Update the \"My Profile\" page to include the SAS checkbox."]

{"sheet":"Definitions","index":4,"n_rows":9,"n_cols":9,"rows_kept":9,"cut":false,"hidden":false,"merged":[[0,0,0,8]]}
["Definitions"]
[null,"Priority","Definition",null,"Status","Definition",null,"Issue Type","Definition"]
[null,"High ","Issue needs to be addressed immediately (before addressing issues of medium or low priority). This includes issues that need to be resolved for the application to function correctly/as required and enhancements in high demand by the community.",null,"Open","Issue has not yet been addressed \n(Issue has been introduced/identified but no formal discussion or action has been considered or taken).",null,"Bug Fix","Change that needs to be made due to the fact that the application is not meeting the original specified requirements. The change will correct the defect so that the application functions as originally planned."]
[null,"Medium","Issue needs to be addressed following the completion of high priority items. This includes issues that are not critical to the functionality of the application but are enhancements in moderate demand by the community.",null,"In Progress","Issue has been addressed; requirements have been clearly identified/created, development is underway, and/or testing is being conducted.",null,"Enhancement","Existing feature or functionality change that is identified through internal and/or external user feedback that improves user experience and/or streamlines the application."]
[null,"Low","Issue needs to be addressed following the completion of high and medium priority items. This includes issues that have little or no impact on the functionality of the application and  enhancements that are in low demand by the community.",null,"Follow-up Needed","One or more people have action items to complete before moving forward.",null,"New Development","Development for new functionality and/or change that needs to be made as a result of external changes that are not initiated or controlled by specified application development (e.g., changes to minimum security requirements that require password change development work). "]
[null,"TBD","To be determined following further discussion/input and consensus. ",null,"Pending Discussion/Feedback","Further NSSP meeting discussions required or awaiting feedback from the community."]
[null,"N/A","Not applicable; issue was deemed a non-issue and no changes will be made.",null,"Complete","Issue is resolved and has been deployed."]
[null,null,null,null,"Code Fixed; Historical Update TBD","Code is fixed and prospective data is corrected; discussion is needed to determine how to deal with historical data affected by issue."]
[null,null,null,null,"N/A","Not applicable; issue was deemed a non-issue and no changes will be made."]