Human Services Data Specification - issues
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

Comment only
Issue NoEntityProperty/AttributesIssueLinkPersonCommentStatus
1n/an/aSelected text:

Controlled Vocabulary

have you looked at integrating any of this with any linked data schemas/ontologies? For example reusing the class and property names from MackayYes, we are receiving input from the Google team and they participated in the recent workshop. Some reuse of class and property names is part of the specification, but there are many domain specific properties not captured by Google has a proposed a civic services schema to W3C and Ohana API already tags the web pages it serves with tags to make the information available to Google's crawlers.
2n/an/aSelected text:

Design Principles

it would be great to see a section here summarizing a review of any existing standards or earlier work and how they relate to this. MackayGood suggestion, will add more material
3n/aEligibilityhere is a preliminary eligibility brainstorm: age (btw 18-99, or 16-24, etc), categories (homeless, victim of DV), referred by (Welfare office, Certain Agencies that they can write out). CaselliThanks for the suggestion, we're compiling them as we receive them
4Programn/aSelected text:


I don't really get the difference btw a program and a service. CaselliA Program is an administrative grouping of services. The grouping maybe based on funding, population served, or services offered, etc. It is an optional entityno change
5n/aInternet ResourceSelected text:

Internet resource(s)

Email should be a separate field than internet resources and required - OR just added on to Contact Attributes and required. This is the 21st century, everyone has email now. CaselliAt this version, the spec is working out vocabulary and not relationships yet. I do think that it would be clearer to move email to contacts since it is attached to a specific person. Good idea.TBD in v0.2
6n/aPhonesSelected text:


Contact info and Phone should be right next to one another... don't make me search for the phone after I found the contact! Also, phone number and email ideally should correspond with contact person. CaselliAt this version, we are working out vocabulary (common terms), relationships are not yet included in the document. Relationships will be presented in the logical model in version 0.2TBD v0.20
7n/aAddressSelected text:

Other address

addresses are only categorized under "mailing" or "other", which doesn't really help if a service has a main office that is only used for larger programmatic issues (like the Seneca Hotel is a hotel of THC's, but all mail that goes to workers at the Seneca needs to be sent to the actual program, but the main office is where any grievances or larger issues go). CaselliAddress are physical, mailing or other. Programs and locations have addresses, but adding an address for an Organization would make sense. It may be redundant in many cases to have addresses for all three entities, but I'll leave it up to developers to figure out the business rules if they don't want multiple entries of the same address, e.g. a Service of Location defaults to the Organization change
8n/aContactsSelected text:

April Smith, Director

it may be a good idea to direct folks to the program level contact as well, since otherwise the director may get wayyy too many emails from clients looking for help. Not sure if this will be clear or not otherwise.

Hailey Pate+1 to caroline's suggestion! CaselliHaving an optional Program contact is ok with me. In the AIRS schema, there is a field that specifies whether to display information or not. I'm in the camp of providing as much information as possible and letting the business rules determine what is shown.Add contact to Program
9n/an/aCould the appendix tables be augmented with information where properties/classes map to schema.orgelements and other ontologies? MackayGood idea, once we get the vocabulary and logical models nailed down, then a crosswalk would make sense.TBD, later version
10Organization IRS StatusSelected text:

IRS Status

could this be made more generic so it is not a US-specific term? MackayThis is an optional field. But would tax status be better?Changed to Tax Status in v0,2
11Organization FEINSelected text:


same for this - US specific MackayWould tax id be preferable?Changed to Tax id in v0,2
12n/aInternet ResourceSelected text:

Internet Resource(s)

how come these are not split out into properties such as website, email, etc? Actually I see the internet resource table below - but why define it this way? MackayAn Organization, Program or Service may have multiple websites or other URIs. Version 0.2 will add in the entity-relationship models that shows that Internet Resource table joined to either a Organization, Program or Service. Currently, the vocabulary is just showing the properties associated with each entry and not relationships.Internet Resource removed in v0.2, to be replaced with web site, email, or other type of internet addres
13Program, Service, Location, OrganizationIdSelected text:


Could a separate description above be given describing the design goals of having elements such as the UUID?

Also wondering why this and not use a Linked Data approach with a defined ontology? MackayIn v0.0, a suggestion was made to use UUID instead of an integer for a unique id that would identify each entry. In addtion to working through developing a controlled vocabulary, we're deciding on the type so it can be imported into a relational database.

I think linked data will ultimately be used to define/overlay different taxonomies on the data. At the moment, the spec is setting the lowest bar for data exchange, which is flat files in CSV with keys for joins.
14LocationPhysicl AddressMoncef Belyamani:

Physical address, mailing address, other address, phones, and internet resources wouldn't actually be filled in the Locations table, right, since there are separate tables for each that point back to the Location via the Resource id.

Neil McKechnie:

I think all location data should be removed from Service and only reside in Location. This would/will allow multiple Locations to offer a single Service, which is fairly common, but keep the data normalized. Belyamni, Neil McKechnieThese aren't table descriptions. This shows what properties are associated with each entity. There is a bit redundancy between Location and Services in order to acommodate models where Locations have Services or Services have Locations. Maybe we should just choose one model.
15Service Service Area(s)Charles Koppelman-Milstein:

Service area(s)Service Area should be more than just a description. There should be an optional Spatial data component to it so it can be placed on a map. It doesn’t always break along Zip or County lines, and might be way too large for a listing of census tracts, as suggested in another discussion as a best practice. Also, globally these terms are all mostly meaningless...

Neil McKechnie:

Often times, the service area is critical for returning accurate search results. I recommend having some method of containing well-structured data here, not just a text field. Koppelman-Milstein, Neil McKechnieMy interviews with service providers indicated that boundaries of service areas tended to be fuzzy and at the discretion of the service provider. While place names are meaningless on a global level, the data is primarily for service providers working at the local level. I'm not particularly against the of well structured data or spatial. data, but it needs to be easily recognizable to users hence using local place names or well known geographic divisions seems to be a better practice. Can y'all provide examples of what you would like to see? The spec can be extended to spatial data for mapping/search purposes but we should weigh complexity against of ease of use.TBD, no action in v0.2
16Service Language(s)It’s useful to know what languages are supported and in what capacity. “Language in which services are delivered” is still a bit broad. I’d love to have a more complex object on par with Wiki:Babel (, ILR ( or some other existing standard. Unlike the 0.0 comment that seems to dismiss this, we’ve found that it’s useful to know that Quechua is spoken via a language line or a volunteer who comes in Thursdays (the Quechua monolinguist would then try to come in on a Thursday), or if a staff member has broken capacity or fluent. We can perhaps develop a standard that’s more complete than Babel, but it doesn’t need to be.

Jennifer StoweIn
addition to the language line, should we explore changing language to "Can non-English speakers be served? If yes, what language?" Bread's social workers think that this question would get better information. Koppelman-MilsteinI think that this would be best if someone wanted to extend the model. The spec is trying to balance simplicity and usefulness against specificity and complexity. We expect this data to be self reported and quite possibly changing frequently. I do think that indicating the availability of a language line would be good to include.

Recommend adding if language line is available.
Add language line in v0.2
17LocationThe physical location of some services, e.g., DV or HT shelters, are intentionally not public. Some services, like chat lines or hotlines, have no physical location. Why should Location be required?

Also, the location data ought to reside in the Location object, right? This is duplicative and potentially confusing to also have it in the Service object. Koppelman-Milstein, Neil McKechnie, Jennifer StoweThere's a bit of redundancy going on to accommodate Services have Locations vs Locations have Services relationships. I'll put this issue out to Google Groups to see if we can get some resolution. This is addressed in the logical model in v0.2
18MetadataI don't see fields in any of the records to denote "Status". Active, Inactive, Defunct, Temporarily Closed (Seasonal), etc are all important things to track and can and do change over time. The specification should come up with a standard list of allowed values.

Manik Bhat
We've dealt with this issue from the perspective of making a correct referral and have termed this as "Capacity". As in, does this location have the ability to accept more clients or not. This is largely tough information to find/update but I believe having some representation of it is very important. McKechnieAgreed, could you provide a starter list?Adding Status to Service in v0.2 as required
19LocationTransportThis field name could be more targeted. "Travel" is vague. How about: "Public Transportation" ?

Greg Bloom:

I asked Janae Futrell ( from the Atlanta Regional Commission, which provides 'demand transportation' (rides from home to service) and here's what she says:

"I think the catch-all term transportation makes sense as your umbrella term. Of course, there would be a subcategory for public transit. For what some call “door to door” or “curb to curb” trips (demand response in nature), ARC has started using the term “specialized services” as another subcategory. The One-Click stakeholders voted on this. Some agencies use paratransit as an umbrella term for this same subcategory, but we have stayed away due to possible confusion with ADA complementary paratransit (a specific type of specialized services that transit agencies provide as a complement to fixed route)."

Greg Bloom via Stephane from Open North (advisor on Open511):

"my impression is that your "transportation" field should be a free text field that contains what the "location" would provide on their website to let people know how to get there. Some will put only public transportation, some will say where to park, which exit use, etc.

If you think that specialized transportation is an important issue for users, that might require a specific field.

Trying to go in a detailed and structured way to provide public and private transportation information will become a nightmare. In general, integration is difficult because there are too many "holes" in the transportation data to provide a clear view on how to go from A to B using different transportation mode. Given your model provides the lat/long, tools that would like to integration transportations tools could do it based on the geospatial information. More integration than that, at the current stage of development of transportation data would make it difficult for your standard. " McKechnieWill put to the group for inputChange to the more generic "Transportation" in v0.2
20Service Parent idIf Programs are the admin grouping of services, shouldn't the parent ID of a service be a program ID? SiruguriYes, that would be the case if we had a model where Program is required. If there is no Program then we can attach Services to the organization. If you want to find Service(s) under a Program, then we would need to have a Program.Id for each Service.

Recommend adding a Program.Id to Service.
Add Program.Id to Service
21ProgramService idHow do you associate more than one Service with a Program? McKechnieI have this backwards. A Service can have an optional Program.IdRecommend removing Service.Id from Program and adding Program.Id to Service
22Service DescriptionCharles Koppelman-Milstein:

Great! But I think limiting it to only Markdown is reasonable. HTML poses a massive security risk. How do we tell which ones have markup? Can we just assume Markdown for all cases?

Neil McKechnie:

Why not just require HTML always be encoded? Koppelman-Milstein, Neil McKechnienoted, but I'm not sure how enforceable this would beRequire HTML to always be encoded.
23Service Location idCharles Koppelman-Milstein:

What does Location mean for a Service?

Neil McKechnie:

Yes, and how does one link a Service to a Location? Koppelman-Milstein, Neil McKechnieThis is similar to previous comments. There's a bit of redundancy going on to accommodate Services have Locations vs Locations have Services relationships. I'll put this issue out to Google Groups to see if we can get some resolution. see Issue 17
24Organization Contact(s)Charles Koppelman-Milstein:

Why make contact name required on an organization? There are organizations out there who are better suited to be more anonymous, especially on a global level, or ones where turnover is high enough to make this unmaintainable.

Neil McKechnieI:


Manik Bhat
Yeah, I don't think this should be required. Usually tough information to find and sometimes the contact listed might not be the contact that is helpful to ensure an successful referral. Koppelman-Milstein, Neil McKechnienotedchanged to optional in v0.2
25Service Hours of OperationMoncef Belyamani:

What about multiple opening times in the same day?


Yes, I'm afraid that's not infrequent for our listings, including lunchtime closings and separate evening programming. There may also be a need for a 'Notes' subfield.


I do suspect we will need to end up with a regular text field for Hours. I know that developers (understandably) always long to digitalize Hours data, but from what I can see there would typically need to also be a parallel text version as well (to accommodate all the anomalies, as well as provide something short, tidy and easy-to-read). More to the point though, the AIRS Standards don't go there, and I think most centres haven't either?

Manik Bhat
We've found a middle ground where we digitize hours data and include any discrepancies in an "additional information" section that is readily accessible. The possible future benefit of having digitized hours (scheduling etc) can't be overstated. Belyamani, johnallec, Manik BhatConsolidating schedule formatting into issue 26see Issue 26
26Service Hours of OperationCharles Koppelman-Milstein:

The pipe-delimited format of hours of operation is rather confusing. Maybe days of the week can be more explicitly prefixed with MTWRFSU to avoid input error. Also, military time notation might be easier to read:

M 0210-1800;T 0310-1800; ...etc.

Finally, should time zone be included and should "Closed for holidays" be mentioned somewhere?

Charles Koppelman-Milstein:

Or see the GoodRelations microformat for this:

Charles Koppelman-Milstein:

...or more relevantly and more cleanly,


Unless the format is quite established, I wonder if most would think of Monday as being 'day 1' (and on the 7th day we rest)?
Charles Koppelman-Milstein, johnallec, Manik BhatIt looks like even Google is inconsistent between and the Places formulation of schedules!

My preference is to use ISO8601 time intervals to represent open and close. For example:


Where D is day of week (Monday =1)
hh is hour
mm is minutes
/ is separator between start and end

So open Monday through Thursday from 9:00 to 4:00 would look like this.


If a place is open with a break it could look like this:


As proposed earlier on, semi-colons are the used as separators in arrays

I'll raise this issue with the group to get consensus on it.
I'll raise this issue with the group to get consensus on it.There didn't seem to much resistance this suggestion
27n/aInternet ResourcePaul Mackay:

how come these are not split out into properties such as website, email, etc?

Paul Mackay

Actually I see the internet resource table below - but why define it this way?

Sophia Parafina:

An Organization, Program or Service may have multiple websites or other URIs. Version 0.2 will add in the entity-relationship models that shows that Internet Resource table joined to either a Organization, Program or Service. Currently, the vocabulary is just showing the properties associated with each entry and not relationships.

Charles Koppelman-Milstein

I agree that it's weird to combine APIs, websites, email addresses, chat lines, and social media just because they share a method of delivery.

I feel like website and email address certainly deserve their own fields, and Social Media might (in the developing world, this is rather a big deal since they often use that as a primary method of contact - maybe something like "Twitter|@foo; QQ|foobar; Facebook|")

APIs seem so separate from any of these. I think what the API really is depends on the purpose of the API.

Moncef Belyamani

+1 to all of this. Just because there could be multiple entries for a particular field doesn't necessarily justify adding a new table. I'm in the camp that believes these should be their own separate fields.

Paul Mackay

Also some (most?) of the key properties probably could have one main value, e.g. an org's main website. Which presumably is how view it.
Ok, so separate fields for Organization and Services. Lose the Internet resources table. They would include:


Anything else?
Internet Resource has been removed in favor of individual fields
28n/an/aTricia Burmeister

"controlled vocabulary" is a term with lots of history in the LIS field, usually used to refer to standardization of the values that are to be used with various schema properties, rather than the schema's properties themselves. I think it's confusing to call this a "controlled vocabulary" b/c the first thing I think of when I hear that is the 211 Taxonomy of Human Services. Might I suggest using "Standard Vocabulary" here instead (or really anything other than "controlled vocabulary")? BurmeisterI'm using 'controlled vocabulary' in the sense that it is a list of terms that have an unambiguous, non-redundant definition. (see I'm avoiding using ontology because it means many thing to many people.

I don't come from LIS field so I'm not familiar with other interpretations of controlled vocabulary. However,I think calling it a Standard Vocabulary is a bit over reaching. I'm happy to call it just a Vocabulary for Human Services, but I'll put that question to the group.
Ask group for opinion
No response, no change in v0.2
29Service Document(s) requiredMoncef Belyamani:

If there are multiple documents that can be entered, it should be specified what the delimiter is (comma, semicolon, etc.) so that it's easier and consistent to parse the data.

Moncef Belyamani

This goes for all "array" type fields that can contain multiple values, like service areas, languages, methods of payment, fees, etc.. BelyamaniA semicolon is specified as a separator for an an array of data in the CSV formatting section of the documentAlready part of specification, no change
30LocationContact(s)Moncef Belyamani:

Aren't Contacts a separate table? There wouldn't be an actual Contacts field in the Locations table, right? BelyamaniRight. These are not tables, they show what properties are associated with each entity.No change in v0.2
31LocationLanguage(s)Moncef Belyamani:

Please consider using ISO 639-1 codes for Languages:

Charles Koppelman-Milstein

I'd suggest ISO-639 but not limit it to the ISO-639-1 two-letter codes. Some languages, e.g., Native Alaskan languages like Tlingit and Aleut, have no ISO-639-1 code but do have ISO-639-2 three-letter codes. BelyamaninotedUse ISO Language codes in v0.2, note that this my require an extra table with language codes and the language
32MetadataDate last verifiedMoncef Belyamani:

Can this be combined with date last action and last action type? Instead of having a separate field, the fact that it was verified (which I'm assuming means no CRUD was necessary) can be an action type. BelyamaninotedDate last verified removed in v0,2
33MetadataDate addedCharles Koppelman-Milstein:

Should deletes also be tracked here?

Moncef Belyamani:

I think "Date added" is redundant since that information is already provided by "Date last action" and "Last action type", which are both required.

Moncef Belyamani:

I think I have to take that back. This metadata is probably just one entry, not an actual history of every single change, right? If that's the case, then the original date of creation should be separate. Belyamani, Charles Koppelman-MilsteinActually it is a history of every change, so Date added is redundant.

Recommend to remove it.
Removed Date added, is covered by Last Action Type in v0.2.
34n/aAddress/Contact idMoncef Belyamani:

I think Contact id might have been added here inadvertently. BelyamaniUnsure if we should provide the mailing address of a contact. Will ask group.Removed in v0.2
35n/aAddress/typeMoncef Belyamani:

The exact allowed values for Type should be specified to ensure consistency. Belyamaniphysical, mailing, other are the allowed typesNo change in v0.2
36n/aPhone/Country codeMoncef Belyamani:

I think this should be required to make it easier to validate the phone number format. BelyamaninotedAdded Country code as optional in v0.2
37n/aPhone/Resource idMoncef Belyamani:

This should include Contacts. BelyamniEach contact has a Contact.Phone_id, i.e. contacts have phones. If this is true then Phone.Resource_id is not necessary, each Organization, Service, or Location will have a So remove Phone.Resource_id.Contact will have a Phone.Id added in v0.2
38Charles Koppelman-Milstein:

Selected text:

Any particular encoding? UTF-8? -16? ISO-LATIN-1? Koppelman-MilsteinUTF-8Addded that UTF-8 will be the character set used in v0.2
39PropertiesCharles Koppelman-Milstein:

Also perhaps add something like "Special populations". So if a service is particular geared toward Native Americans or Transgendered people or Men or Teenagers or Migrant Workers, but accept all sorts of people, then they can say that. Koppelman-MilsteinThere's an Eligibility property that will enumerate special populations. We're waiting on input to compile a listMoved to eligibility
40OrganizationCharles Koppelman-Milstein:

Does coordinating services count? Koppelman-MilsteinYesNo change in v0.2
41n/an/aCharles Koppelman-Milstein:

CSVs are absolutely easy to produce. However, it would be great for consumers of this data if an org could publish a single file with all the information regarding its information and services and include it in a vCard like thing. Or at least post it on the web easily.

Hailey Pate

That is an awesome idea... but I agree it's beyond the scope of this spec. OpenReferral should definitely consider an org-centric "something" down the road! Koppelman-MilsteinI think that is an organizational decision and not one within the scope of the specNo change in v0.2
42n/an/aCharles Koppelman-Milstein:

Linked data would really help with data provenance Koppelman-MilsteinI would be interested in seeing examples.
43ServiceWaitCharles Koppelman-Milstein:

Starting when? When a phone call is made to initiate the process? When documents are received? When the application's been approved? When payment is made?

Ending when? I assume this is the first moment a person can access the service and not, e.g., the length of time until the person has completed their course of ...whatever.

This is free-text and therefore can describe all of that easily, but isn't easy to search.

However, if it were constrained to a definition, and could be an ISO duration value like PT1H for 1 hour (see then this could be more searchable. Koppelman-MilsteinI don't disagree with any of this comment, but I think that this property will not be often filled in. I'm leaning towards approximations rather than strict definitions for wait times until service is rendered.No change in v0.2
44Servicen/aCharles Koppelman-Milstein:

What defines a service? I see some strange things in the "Example" section of "Application process" that make the definition seem organization-defined, and not Open Referral-defined. I'd think that even if an org only provides groceries as part of their case management work, that's two services - food pantry and case management. But I don't have the same depth of knowledge as the others who crafted this document (I'm mostly a programmer), and I'd like to understand what Service means to the folks here. Koppelman-MilsteinThe Organization defines a service. It's beyond the scope of the spec to define and enumerate services.No change in v0.2
45OrganizationAccreditationCharles Koppelman-Milstein:

Is Accreditation on the Org or on the Service? Same with license, actually. Koppelman-MilsteinOrganizations hold the license or accreditationNo change in v0.2
46OrganizationLicenseCharles Koppelman-Milstein:

Licenses could be broken out into license type, licensing agency, and license number. The number alone is not very useful in an org with a soup kitchen and a shelter. Koppelman-MilsteinUnclear if this level of specificity is needed for an optional property. change in v0.2
47n/aAddress/Street_1Charles Koppelman-Milstein:

Internationally, there are places with much more onerous needs for addresses. In other databases I've worked with, I’ve usually seen: AddressLine1-4, City, State/Province, Postcode, Country. City is sometimes called “Locality” and State/Province can be called “Region”, but that's not that important to me. Having enough fields to describe an address is important to me. Alternatively, Street_1 and Street_2 can be combined into one field, and just use pipes to indicate where newlines go (and \| to indicate a pipe... and \\| to indicate a slash and a newline...) Koppelman-MilsteinNoted, but will eschew combining address into a single property to facilitate change in v0.2
48n/aAddress/CountryCharles Koppelman-Milstein:

Please use ISO codes for country and state codes, here and in the Location object. Koppelman-MilsteinGood idea.Both ISO 3361-1 (country) and ISO 3361-2 (state) codes have been specified in v0.2
49n/aPropertiesCharles Koppelman-Milstein:

Add Memoranda of Understanding (regarding how a service can be provided) either here or on Organization Koppelman-MilsteinUnsure what this means, can you explain further?No change in v0.2
50Service, LocationAddressCharles Koppelman-Milstein:

I'm confused why there's two places to store this data - the Service's Location and the Service itself. Can we cut that down to one? Koppelman-MilsteinThis is an artifact from not having an explicit relationship that Services have Locations or vice versa. It will be be cleared up by the next iteration.Resolved in v0.2 logical model
51N/aInternet ResourceCharles Koppelman-Milstein:

Not everyone has email. Especially not globally, but not even in the US. Koppelman-MilsteinWe'll most likely do away with internet resource and add properties to the entitiesInternet Resource removed in v0.2
52n/aPhone/TypeCharles Koppelman-Milstein:

SMS short and long codes should probably be explicitly mentioned so tool-creators don't try to use standard phone number validation rules. Koppelman-MilsteinSMS will be its own propertySMS added independently of phones in v0.2
53n/aPhone/TypeCharles Koppelman-Milstein:

I feel like a hotline is more of a service than a phone number. A hotline needs a phone number, but it is much more than that. Koppelman-MilsteinNoted, will put that to group for discussion.No change in v0.2
54OrganizationAlternate name(s)Charles Koppelman-Milstein:

It would be useful to include “Language of alternate names”… So Alternate Names becomes an array of objects like: [{lang: ‘en’, name: ’Starlight Foundation’}, {lang: ‘es’, name: ‘Fundación de la Luz de las Estrellas’}, {lang: ‘es’, name: ‘FLE’}]... In CSV format, to make language optional, this might mean pipe-delimiting the language, like: "en|Starlight Foundation; es|Fundación de la Luz de las Estrellas; es|FLE" Koppelman-MilsteinUnsure that an optional field warrants that level of specificity. Again balancing usefulness and complexity.No change in v0.2
55ServiceLocation idSameer Siruguri:

Might it make sense to make this required? O/w it looks like Services can be entirely virtual because no other related entity appears to have a required Location (unless I'm missing something) SiruguriI think there will be more services offered virtually in the future via apps. For example, I've seen PTSD buddy apps that keep people suffering form PTSD connected if they need to speak to someone. So, I'm not sure how to describe the location of something like that, maybe the URI?
56Organizationn/aAkshai Prakash:

I realize that the use of NIEM is not really being discussed much anymore but this is a great way to leverage NIEM without actually having to worry about using the schemas or developing the IEPDs. NIEM already has an engaged group from human services (through its human services and cyfs domain) that have agreed to the terms that you have listed below so need to go through the effort of having to re-define them.

Hailey Pate

One of the drawbacks with using an XML-based format like NIEM for the early versions of the HSDS is that small non-tech savvy organizations can't work with XML. But almost all of them have access to spreadsheets.. therefore the CSV-oriented work being done has the potential to address a much broader audience.

My feeling is that future versions of HSDS will become available in XML and JSON as well, and that will be the time to really dive into NIEM. So...

Akshai, can you recommend any "off the beaten path" sorts of resources for getting acquainted with who the NIEM human services stakeholders are and their progress to date? I haven't had much luck with getting recent news from the NIEM website... Prakash, Hailey PateWill probably visit NIEM when building crosswalksNo change in v0.2
57n/an/aAkshai Prakash:

The primary use case served by Open Referral is the provision of information about many organizations to a common or overlapping audience.

Consider rewording.

Greg Bloom:

Akshai, can you clarify what rewording you think might be in order?

Greg Bloom:

I would say that 'organizations' should be replaced by 'services' -- but not sure what else is unclear here.

Hailey Pate +1
Akshai Prakash, Greg Bloom, Hailey Pate
note, will change to 'services'organizations' changed to 'services' in v0.2
58n/an/aAkshai Prakash:

How do you differentiate the human services domains? What are some?

Greg Bloom

Good question. But it's a procedural one. Better to put to the workgroup and/or articulate in project documentation, not the model's documentation. Prakash, Greg BloomGreg Bloom

Good question. But it's a procedural one. Better to put to the workgroup and/or articulate in project documentation, not the model's documentation.
no change in v0.2
59n/an/aAkshai Prakash:


I have heard the word "lineage" being used much more than provenance. Maybe state that you are basically referring to the same thing PrakashLineage is commonly used for metadata. There's an assumption that the organization/service provider will be maintaining their information, so provenance seems to be more fitting because the data points back to the organization.No change in v0.2. Regardless of how the data is maintained operationally, the data should point back to the originator organization.
60n/an/aAkshai Prakash:

simplest useful thin

Need to more clearly state what you mean by this. Sounds too arbitrary. PrakashGreg Bloom

The principle is simplicity. Not sure I follow why we would want to complexify our definition of simplicity.
No change in v0.2
61n/an/aAkshai Prakash:

five principles

I would add a footnote to define each as it would relate to this context. PrakashGreg Bloom

How would the definitions be different from the paragraphs below?
No change in v0.2
62n/an/aAkshai Prakash:

use case

I would call out some use cases of where this spec might be applied as well as the problem that it is trying to solve. PrakashGreg Bloom

The following paragraph points to the problem. Not sure we should get more elaborate in this document, which is not intended to make a case.
Added the four use cases in v0.2
63n/an/aAkshai Prakash:

verifiable and can be reproduced across different systems and applications

Not sure how a metadata model spec confirms this. PrakashMetadata isn't intended to do this. This has to be done by the community of interest.No change in v0.2
64n/an/aAkshai Prakash:
The data provided in the Human Services Data Specification are factua

Its this specification more of a metadata model? If so, not sure how you can assert this statement. Consider revising. PrakashIt's not a metadata modelNo change in v0.2
65n/an/aAkshai Prakash:

use case

I would actually call out some tangible use cases, and the problems that this spec is trying to solve. PrakashOK, will add four user types
Added the four use cases in v0.2
66EligibilityAndrew Lomax 2:15 PM Aug 21
Add: “Gender Specific services ( Male, Female, Transgender, Transgender - M to F, Transgender - F to M )”
Add: “Age service is restricted to, integer 0 - 100”
Add row: with text “Maximum Age Age services is restricted to 17”
Add cells: with text “Children Require dependents Yes Maximum Income Maximum income per month in USD $500 Disability Requi…”
Add: “Transgender - M to F”
Add: “60”
Add: “Minimum Age”
Add: “Gender”
Add: “Age” LomaxCombined mutliple comments Eligibilty should be a field, however unsure how to add multiple criteria with each having an enumerated set of values, e.g.:

Gender: Male;Female; Transgender; Transgender M to F; Transgender F to M
Age: 0-5;6-10;11;15;16-20; ...
Maximum Age: 17
Minimum Age: 5
Main menu