Age-based eligibility

[timgdavies]

In #156 @klambacher says:

We have a requirement to record minimum and maximum age data which is used for searching purposes. Is possible to recommend a structured format for an entry that describes an age range, so that it could be consistently parsed?

At present, eligibility is a table in a one-to-many relationship with services, with eligibility values taken from a codelist.

Options might be to:

• Add eligibleAgeRange to service with a simple range (e.g. 10-18) (allowing a single age range per service)
• Support presentation of a range in eligibility table
• Add some specific age range properties to eligibility

Considerations may be:

• Whether ages are always whole numbers (e.g. are some eligibilities recorded as for children above 7 1/2?) or whether they are numbers at all (e.g. school grade levels)

[klambacher]

Note that ages must be decimals. Services for small children are often in part years. Also, it must be possible to omit either the minimum or maximum age and have only one boundary.

[mathewtrivett]

You could look at the ageRange property in the Recommended Fields of the OpenActive standard. Being compliant with OpenActive opens up other use cases to exchange data modelled in the OpenActive standard.

Examples

18+

"ageRange": {
  "type": "QuantitativeValue",
  "minValue": 18,
  "maxValue": null
}

0 - 6 months

"ageRange": {
  "type": "QuantitativeValue",
  "minValue": 0,
  "maxValue": 0.5
}

11 - 16 years

"ageRange": {
  "type": "QuantitativeValue",
  "minValue": 11,
  "maxValue": 16
}

Under 50

"ageRange": {
  "type": "QuantitativeValue",
  "minValue": null,
  "maxValue": 50
}

[robredpath]

MINOR - "Add eligibleAgeRange to service with a simple range (e.g. 10-18) (allowing a single age range per service)"

MAJOR - OpenCommunity's suggestion of a link table, which could then allow a richer expression (or multiple, richer expressions) of age ranges.

[mathewtrivett]

@robredpath would this be as numeric values rather than as a string? I feel we may loose some powerful functionality if it were to just be a string value e.g. "10 - 12"

[MikeThacker1]

In our UK work we proposed (from UK OpenCommunity discovery recommendations) that service eligibility has minimum and maximum age numeric fields. Taxonomy items can be used for other types of eligibility, but for age we really need to be able to do some numeric comparisons. Hence two numeric fields rather than one string.

@mathewtrivett 's proposal of an ageRange object makes sense in JSON but this is complicated to represent in a Tabular Data Package, which is used by Open Referral to represent the single source of truth.

[AtticusRains]

MINOR - "Add eligibleAgeRange to service with a simple range (e.g. 10-18) (allowing a single age range per service)"

@robredpath would this field make more sense to add to the Eligibility table rather than Service?

[MikeThacker1]

Yes @AtticusRains we definitely saw it going in Eligibility. Thanks for clarifying that.

[Cskyleryoung]

@MikeThacker1 , I read that eligibility is being deprecated. Consequently, my team is using taxonomy_term plus service_attribute and other_attribute to replace it, in the main. However, something like age range seems like it provides a case for keeping eligibility in order to provide some disambiguation. Perhaps not all eligibilities are best expressed as taxonomies?

[MikeThacker1]

It would be good to know how others are dealing with age eligibility.

The suggestion to consider removing eligibility was on the basis that it is currently not being used (in open data feeds) for combinations of eligibility criteria and a better approach to complex eligibility rules in the future is to agree on a JSON standard for defining such rules and maybe put that JSON in a text field.

The suggestion to consider removing eligibility went along with a proposal to add a "value" field to service_attribute and other_attribute. Would that work?

[Cskyleryoung]

Thanks for the history Mike, that does make sense. I would be fine with that, personally.

The possible usage of service_attribute or other_attribute for both storing values and referencing other tables is a little weird, but I'm no DB admin, so perhaps that's a typical pattern.

On Tue, Feb 22, 2022 at 3:28 AM MikeThacker1 @.***> wrote:

It would be good to know how others are dealing with age eligibility.

The suggestion to consider removing eligibility was on the basis that it is currently not being used (in open data feeds) for combinations of eligibility criteria and a better approach to complex eligibility rules in the future is to agree on a JSON standard for defining such rules and maybe put that JSON in a text field.

The suggestion to consider removing eligibility went along with a proposal to add a "value" field to service_attribute and other_attribute. Would that work?

— Reply to this email directly, view it on GitHub https://github.com/openreferral/specification/issues/163#issuecomment-1047593488, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAYZRPOL3EF56RO476RHNMTU4NJNLANCNFSM4DWJPPLA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[mrshll1001]

I'm tentatively closing this since:

• It appears that eligibility is no longer a field in 3.0
• 3.0 now has an attribute object (or table, as it were) which has a value field and taxonomy_term field which matches the use-case descriptions in this thread
• There is a wider discussion on modelling eligibility that is out of scope for this ticket, but I am saving a link to this ticket so that this discussion is not lost and can be referenced as part of that work.