search

fureigh / drupal-open-referral

An oh-so-in-progress Drupal distribution for Open Referral/Ohana.
1 stars 0 forks source link

Outline intended fields #11

Open fureigh opened 9 years ago

fureigh commented 9 years ago

Working with reference to Populating the Postgres database from OpenReferral-compliant CSV files.

kaypro4 commented 9 years ago

With an eye towards building out an MVP from a data management level.

kaypro4 commented 9 years ago

@fureigh making some progress on this tonight. It was moqups that I was thinking of this morning, not balsamiq. Here's a start at a core set of objects and fields: https://moqups.com/i8flan/BCUEl52h/p:aaac69283

Let's look it over when we talk next week since it probably requires some explanation.

The concept of creating referenced nodes from within the referencing nodes relies on something like the "References Dialog" module that doesn't seem to have an 8 branch yet. It also relies on something like "Field Group" that does have a 8 branch at this point.

fureigh commented 9 years ago

@kaypro4 Nice! And thanks for the moqups tip.

One initial thought: let's include program description as well as name, as program names often don't convey sufficient information. Excited to hear you talk through the rest next week!

kaypro4 commented 9 years ago

@fureigh I kinda just plopped program in there not knowing how it is intended to be used. In Ohana and the HSDS 1.0 there are only id (primary key), Organization_id (foreign key), name and alternate_name in the program table so it's pretty thin. I just looked back at the HSDS spec doc and found this tidbit that might be helpful:

"The Human Services Data Specification seeks to establish a common vocabulary among information and referral (I&R) practitioners. The vocabulary reflects the simple model of four required entities: Organizations, Locations, Services, and Metadata. An optional entity is Programs, which is available for organizations that use Programs for grouping Services. Entities have attendant properties and some properties are complex and have multiple attributes. For example addresses are comprised of several pieces of information.."

Used in this context above it seems that adding a description makes a lot of sense. A description makes sense to better describe a group than just a name.

So I'll throw it on the wireframe but I think it makes sense to flag it as "not in HSDS" just so we don't forget where we're matching and where we're different. All the rest of the fields and relationships are directly mirroring HSDS at this point. But all are open to discussion of course!

kaypro4 commented 9 years ago

@fureigh well, I guess this all needs a second look and lots of discussion... I had program on Org but it should probably be on Service. I'll stub it in for now and we can work through it more next week.