Data Governance Toolkit: Data System Changes

Data System Changes [PDF]


Data System Changes icon

State Part C and Part B 619 programs will encounter the need for changes in their data system(s). Many changes to an existing data system can affect work conducted at the state, local/district, and/or provider levels. Even the addition of a single response option to just one established data element could have significant and far- reaching implications to business rules, data collection screens, supported forms, post-collection analysis, reports, data dictionary, trainings, and the like.

Therefore, while Part C and Part B 619 staff may not be directly involved in the technical changes made to data systems that directly affect their work, the state should establish a process for Part C and Part B 619 program staff to be actively involved in partnering with information technology (IT) staff when considering data system changes that will affect their data and work. This section of the toolkit aids in the development of comprehensive data governance policies to support Part C or Part B 619 consideration of potential data system changes and when and how to make such changes.

Considering a New Data System?
This section of the Data Governance Toolkit focuses exclusively on policies for change(s) to existing data systems, not new data systems. Adding a new Part C or Part B 619 data system or replacing an old system is a decision predicated on factors external to established Part C and Part B 619 data governance.

Records that have a re-identification code and have enough personally identifiable information (PII) removed or obscured so that the remaining information does not identify an individual and there is no reasonable basis to believe that the information can be used to identify an individual. The re-identification code may allow the recipient to match information received from the same source.

A decision that a new system is decidedly better than enhancing an existing system is based on many considerations. Such a conclusion is supported by: availability of funds (immediate and sustaining), political climate supportive of both state agency and local-level changes required with a new data system, technology alignment, internal and external agency data integration efforts, etcetera.

Recommendations or requirements to make changes to a Part C or Part B 619 data system(s) may emanate from many different sources. New or modified federal and/or state data collection or reporting requirements, changes to internal program data needs (e.g., monitoring, new reports),recommendations from stakeholders in the field, agency or cross-agency data integration efforts, technical architecture changes, updates to security, new requirements from information technology—many sources can trigger a request to change the content, functionality, technical aspects, or reports associated with an existing data system. Regardless of where the recommendations for change come from, data governance policies should reflect the involvement of Part C or Part B 619 program representatives in considering and deciding data system changes affecting their programs. In many cases considering a data system change will require Part C or Part B 619 program staff work closely with agency information technology (IT) staff so all will understand the overall impact of the requested change.

It is important to consider the scope and identify the potential impact(s) of any proposed system change. A proposed system change can be small and quick to implement such as addressing a minor bug or spelling error. It can be scheduled and routine, such as an annual update to a list of active agencies. Or it can be complex and long term, such as a multiphase enhancement over an extended period to collect more data and develop more complex reports. While a request to change should detail what is desired to be changed and why, a decision to change focuses on the impact the change will have. It is important that Part C and Part B 619 staff with content knowledge, as well as IT staff with data system knowledge, share perspectives on the change impact. Logically, not all change requests necessitate the same level of consideration. For example, correcting a misspelled word might require no additional input and has little (or no) system impact. In contrast, significant consideration would be required to decide on proposing a data system change to add a new data element such as medical diagnosis or updating service delivery codes.

Part C and Part B 619 programs operate within the state agency in which they are housed. Thus, the structure and content of any data governance already within an agency is of particular importance. Before developing a data system change policy, Part C and Part B 619 programs should review policies regarding data system changes developed by the agency in which their program resides. Existing policies might need to be updated with specific references or provisions related to Part C or Part B 619, in which case the considerations and the template below may be helpful in proposing language.

Where no policy on data system change exists or a separate policy related to Part C or Part B 619 is needed, the template following the Considerations section is fully editable and prepopulated with language to expedite writing new data system change policies for this purpose.

The DaSy Data System Framework describes all major aspects of developing a new and enhancing an existing data system in the System Design and Development section, Quality Indicators SD1 through SD9, in the Data Governance section, Quality Indicator DG3, and in the Sustainability section, Quality Indicator SU1.


Use the questions below to discuss, consider, and develop a data system change policy. Where appropriate, procedures and operational manuals that detail specific actions supporting implementation of this policy should be created.

1. Data System Change: General Provisions

  1. Are there state agency policies related to data system changes that apply to the Part C or Part B 619 program? If yes, what are they?
  2. What specific Part C or Part B 619 data system change policies or procedures, if any, exist and apply?
  3. Which role, within what agency/program should be contacted with questions about this policy?
  4. Which role, within what agency/program is responsible for ensuring adherence to this policy?
  5. Which role, within what agency/program is responsible for monitoring adherence to this policy, and how will the monitoring be conducted?
  6. Which role, within what agency/program is responsible for managing the implementation of this policy including provision of training and technical assistance?
  7. What consequences, if any, will apply when this policy is not followed?
  8. How often will this policy be reviewed for necessary revisions?
  9. How will the public be informed about this policy? Where will it be posted on the state’s website?

2. Data System Change: Initiation of Request

  1. What is the standardized request process for suggesting changes (e.g., a paper/online form to complete, an individual to contact)?
  2. Which role, within what agency/program, should receive data system change requests, and how are these requests communicated to the Part C or Part B 619 program?
  3. What is the process for acknowledging receipt and responding to a data system change requester?
  4. How are data system users informed of the process for suggesting data system changes?

3. Data System Change: Request Required Information1

  1. What information is required to request a change? Shall a requestor (internal or external to an agency) specify exactly what they would like changed with respect to Part C and Part B 619 data system(s)? For example, requested change details might be associated with:
    1. New (or removed) item/field
    2. Item response options
    3. Descriptive text (e.g., item, response option, element definition, application instructions, documentation)
    4. Business logic (validations)
    5. User interface
    6. Dashboards
    7. User permissions
    8. Data exports
    9. Embedded reports, system reports, tools
    10. System speed/capacity/scalability
  2. Shall a requestor (internal or external) provide a rationale for the change request? That is, shall the requestor justify why the change is being requested?
  3. What additional information on the impact of the requested change on affected items will be gathered? (Much of this information will be provided by IT staff with Part C and Part B 619 staff providing content knowledge.) For example, what will be the change impact on:
    1. Business logic (validations)
    2. User interface
    3. Dashboards
    4. User permissions
    5. Data exports
    6. Embedded reports, system reports, tools
    7. Data analysis
    8. Continuity of pre-change data with post-change data
    9. Technology (hardware, software, hosting, security, performance, system speed/capacity/scalability)
    10. Agency staffing needs to design, develop, test, deploy, support
    11. Internal agency functionality and processes
    12. Budgets (short term, mid-term, long term, maintenance)
    13. Local agency: systems, processes, staffing, etc.
    14. Training (internal and external) to inform stakeholders of the change and ramifications of the change
    15. Timeline to support and implement the change (communicating with stakeholders about upcoming change, scheduling change, implementing change)
  4. In what circumstances will Part C or Part B 619 collect information from stakeholders to inform the decision(s)? What stakeholders, (e.g. local IT staff, content staff)? How will stakeholder information be collected and processed (e.g., surveys, focus groups, rank order priority changes)?
  5. In what circumstances will a cost/benefit analysis be needed to address issues related to costs (local and state agency impact, vendor, technology, etc.)? Which role, within what agency/program, will decide if a cost/benefit analysis is required?

4. Data System Change: Evaluation of Request

  1. Which role, within what agency/program, is familiar with the data system targeted for change and therefore shall review the request for completeness, benefits, and redundancy?
  2. Which role, within what agency/program, is familiar with relevant technical aspects of the request and therefore shall review the request and determine the technical feasibility?
  3. Which role, within what agency/program, shall review the impact of the request on costs, expected time to implement, training, etc.?
  4. Which role(s), within what agency/program, will review the request and all associated information and approve or deny the request? What role do Part C and Part B 619 programs play in this process?
  5. What is the process for communicating a content decision or recommendation to all interested parties (e.g. requestor, administration, IT)?
  6. Within what time frame shall the decision regarding the change request be communicated to the requestor?
  7. What role do Part C and Part B 619 programs play in processes supporting the evaluation of the change request?

5. Data System Change: Planning for Change

  1. What is the process for implementing an approved data system change? For example, is a project manager assigned to large enhancement efforts (that may contain many changes)? Are smaller changes overseen by content or technical staff? Will there be a plan and schedule to support proposed changes? If so, how will plans and schedules accommodate stakeholder input and support local agency lead time to accommodate changes?
  2. How will stakeholders be kept apprised of upcoming planned system changes (e.g., newsletter, webinar, newsletter, trainings)?
  3. Which role, within what agency/program, will make changes, and how, to program and technical documentation based on the data system change (e.g., collection forms, data dictionaries, report titles, support manuals, system service documentation)?
  4. What role do Part C and Part B 619 programs play in supporting the plan to change?

6. Data System Change: Implementation, Management, Confirmation, and Communication

  1. Which role, within what agency/program, will oversee the design, development, testing, and deployment of the data system change?
  2. Which role, within what agency/program, will test and review that implemented system changes work as designed? How will tests be conducted? Will it include local stakeholders?
  3. Which role, within what agency/program, will distribute change details to all relevant parties (e.g., programs, participating agencies, vendors)? How?
  4. Which role, within what agency/program, will determine that no further actions are needed relevant to the change (close out the request)?
  5. Which role, within what agency/program, will confirm (if warranted) that the data system change is supported (e.g., maintenance budget)?


  1. Many possible data system change areas are listed. Though content may be helpful for classifying and reviewing data change requests, each specific area does not need to be included within a Part C or Part B 619 data system change policy.

Data System Change Policy Template

Use, and modify as needed, the template linked below for developing a data system change policy. Select the highlighted text and replace with your state/program information. We recommend that you consult with relevant staff and stakeholders when developing these policies. Upon completing the template, be sure to follow your state’s processes for finalizing and enacting policy.

Download Template for Data Governance Data System Change Policy