GrandFamilies Study Commission: Fourth Meeting

Today was that next meeting.  A bit light on the attendance but hey, everybody’s busy and Christmas is coming up fast in the dashcam. Most of the meeting was spent in a presentation concerning child screening – quick or long assessments looking for issues.  The premise is that the earlier problems are found, the faster (and cheaper – money DOES count!) that interventions are implemented, the sooner a child may overcome those problems.  There was also a long discussion on “Kinship Navigation” but more on both later.

Each meeting puts time aside for the Working Groups to work as a team.  We’re also supposed to try to meet in between but I do have admit, having been appointed the Chair of the Data Working Group (er, it was more of a coup FOR me being such as all of my three teammates simply declared “you’re the computer guy, you’re it by fiat”), I hadn’t done all that much since the last meeting. So, this morning, I got up early and assembled my thoughts as a version 0.01 document. Really, more musings than anything else and I tried to put them into some kind of ordered process.  The main idea was to keep my teammates thinking about data across the totality of the problem domain – Grandfamilies. How to identify them, how to locate them, what are the kinds / makeups of Grandfamilies, and how to help them. Co-incident with that was the idea that this exercise is NOT to service just one type of organization (as was first brought up when Data was discussed).

So, I gave it to MaryLou Beaver, Chair of the Commission, and my teammates – they had some favorable things to say about it. So, I present it to you!  For those of you in IT, this should be standard stuff for acquiring software requirements for an new application. Except this isn’t for an application in the traditional sense.

Our mandate, is a bit modified as our target audience is neither IT or Senior Management looking for a GO light and funding to develop something new.  Instead the mandate of the Commission is to provide information and recommendations for NH Legislators in both the NH Senate / House with respect to GrandFamilies where Data is only one component – services, legal / medical / basic needs issues, and the like are the real products of the Commission where Data is, as always, supposed to be a foundation under all of those.  The true end result is supposed to be new legislation in trying to cope with an enlarging cohort of GrandFamilies (families, either by formal means like TMEW, the Grandson, and I, or informal ones by dint of necessity outside any formal processes (e.g., legal proceedings). But I digress. Again, take the below as it was meant: notes presented in a semi-organized fashion

**********

SB131 Commission to Study Grandfamilies

Data Working Group – Identify needs and collection tools available

Jennifer, Jerry, Tracy, Skip

Fundamental Issues:

1. What are the questions to be asked of the Data by Stakeholders?
2. Where does the Data to answer those questions reside? What are the Data types (kinds of Data) needed to answer the questions?
3. What is the process to gather that Data?
4. What are the barriers to gaining access to that Data?
5. How good (or bad) is the quality of the data obtained?
6. How to organize that Data so as to transform it to become Information?
7. How to publicize this Database / Knowledgebase?
8. How to make this Database / Knowledgebase accessible to Stakeholders?

1. What are the questions to be asked of the Data by Stakeholders?

This Working Group assumes that, even as some of its members are experts in this field, it doesn’t know all of the answer, and thus, the questions. There will need to be some type of process, as yet undefined, to:

• Determine who those Stakeholders / Data Consumers might be? A partial list:

• • Legislators
  • Grandfamilies themselves
  • Service Groups
  • Advocacy Groups
  • Healthcare Organizations
  • Government Departments

• Determine what the purposes / mandates / needs are of those Stakeholders / Data Consumers? A preliminary list:
  • Legislators
    • Determining the universe of the problem domain
    • Crafting position papers to address what Government can be doing in response.
    • Creating Legislative drafts that would put philosophy to action
  • Grandfamilies themselves
    • Do I need help? In what areas (e.g., financial, legal, healthcare, basic needs, respite, transportation, school assistance / assistance in dealing with schools, et al)
    • Who can help me? Help my grandchildren?
    • Where are they?
    • How to contact them?
    • What do I or WE need to do in all this?
  • Service Groups
  • Advocacy Groups
  • Healthcare Organizations
  • Government Departments

Each of these are going to need different answers to a whole range of questions. Some questions will be shared but many will be singular purpose(s) of each individual organization.

This Working Group should come up with:

• A preliminary list of questions derived by a simple polling of the organizations represented on the Commission to serve as a partial example of this first sub-problem domain.
• Proposed mechanisms to elicit more questions

This is a FUNDAMENTAL issue to be examined and implemented. Without the “Questions”, any resulting Database / Knowledgebase will be limited in use in the best case and totally useless in the worst case.

2. Where does the Data to answer those questions reside? What are the Data types (kinds of Data) needed to answer the questions?

This will end up, we presume, to be the same Stakeholders / Data Consumers in issue #1. We also presume, at this time, that every single individual / organization not only has questions but also possess, in part, some of the Data to answer the questions.

The problem is that while they are experts in their own problem domain (e.g., their slice of this pie), their knowledge across the entirety of the GrandFamily public domain is limited. Further, each data point they have may be replicating other Data Sinks and, worst case, in differing formats.

Some Data Points / Types are easy to ascertain:

• Mappings of GrandFamily types
  • Full time (24/7/365): informal status (known or unknown), Foster families status, Legal guardians / family care giver status, Adoptive GrandParents, other)
  • Part time (daily / nightly babysitting, short term care due to AWOL parents, et al)
• GrandParent Demographics (age, working status, legal status, financial status, health status)
• Child Demographics (age, education needs, mental illness needs….)
• Where are they? (Geolocation distribution / densities)
• Distance from needed providers
• Socioeconomic data
• Living arrangements (in their homes / apartments, in Parent homes)

Some Data Sources:

• Family Resource Centers
• Advocacy Groups (such as those on this task force)
• Insurance / Medicaid / Medicare
• Schools (Admin, Guidance counselors, teachers)
• Dept of Ed (NH and Feds)
• DHHS
• DCYF
• Daycare Centers
• Legal Aid / Court systems (Family Court)
• Food Pantries
• Town Halls (e.g, Senior Centers, Property Tax adjustments)
• Health centers (hospitals, hospice, gerontology clinics, pediatric clinics)

Similar data points for each of the Stakeholders in #1. Each of the organizations represented should be able to provide this Working Group with the Data Types it now has internally to add to this working list.

This Working Group should derive a limited Data Dictionary so as to show some of what might be needed in the Database / Knowledgebase.

3. What is the process to gather that Data?

Once the Questions are gathered and the Data Points / Types become clearer (not clear, just clearer), the obvious question is:

How do we get it from a given Data Source?

It is assumed (bad word but go with me here for a moment) that some organizations will have their data in electronic format:

• An application they are using for managing their businesses
  • Proprietary
  • Home grown
• Some home grown / ad hoc database (or collection of databases / spreadsheets)

Others, unfortunately, may have reams and reams of binders and books. Perhaps in others, that Data is located in some person’s head. In the case of GrandFamilies, the GrandParents will need to be verbally queried and the answers turned into data.

Thus, it will be needed to create:

• Database or application queries / “spiders” / bots to access the electronic data stores ( “Pull” mechanisms)
• Processes that can accept files / emails / messages on an inbound basis
• Purpose built applications for manually gathering (e.g., either computer or paper based)

The Working Group will need to provide a number of examples of sample processes / protocols to:

• show the difficulty of gathering the needed data
• demonstrate that a number of techniques are going to be necessary in order to query the different Data Sources

4. What are the barriers to gaining access to that Data?

Co-incident with the processes to gather the Data is the ability to legally obtain this data. Some is public domain information – one has to only find it and add to to the list of Data Sources. Other sources will not wish to readily give up their hard won (and sometimes, gained at no small expense) data. Still more will be behind legal or regulatory walls (e.g., FERPA, HIPPA, medical / legal confidential processes).

This Working Group will need to report, in more detail, these problems and, perhaps, mechanisms that would incentivize various entities to “share” (and not punish or mandate).

5. How good (or bad) is the quality of the data obtained?

“GIGO” – Garbage in, garbage out”. Any designer / implementer knows this axion well. Your information system, be it manual or computerized, is only as good as the Data is runs on. Data coming in from a variety of sources should always be looked at in a “guilty” fashion until it is proven to be “innocent” (or “clean”).

MUCH time will be spent on determining:

• where it came from?
• what is its format?
• is it “reasonable”?
• has it been checked?
• Can it be checked against other sources
• what could be the mechanisms by witch the data is confined, cleansed, or rejected?

This Working Group must emphasis that this will be one of the hardest areas that will have to be addressed. It is one thing to handle even within an enterprise – the Data solution here will be confronted with many Data Sources (and the people behind them) that may not have a strong IT team that has been auditing their data with any regularity.

It will also be one of the more expensive areas in the totality of this effort.

6. How to organize that Data so as to transform it to become Information?

Data is nice to have but means nothing if it cannot be turned into information that answers Questions. This, again, shows the importance of #1. Only by understanding the top level of the Questions AND what they mean at a deeper level (e.g., ok, what are they REALLY asking for?) can designers start to create Data Structures into which the Data (now that it has been identified, gathered and cleansed) can be placed.

The Working Group will need to ensure that the message will be that this will be an iterative process as:

• Not all Questions will be known at the start
• The universe of Questions will change over time
• New Data Points may pop into existence in the future while older ones expire
• Needs will change and the Data will have to change with it.

7. How to publicize this Database / Knowledgebase?

You can have a perfect Database / Knowledgebase set up and ready to go but if no one knows about it, it is a complete waste of time, money, and expertise. There will be a need to publicize and market this resource to the Stakeholders.

8. How to make this Database / Knowledgebase accessible to Stakeholders?

This consists of several parts:

• How will Stakeholders actually access it?
• Who will control access to it, and to what parts?
• Will it be widely available?
• How will the information be presented?
• Report formats
• Visualizations

**********************

More to be determined.