Gap analysis: OpenReferral vs Ohana

[ekoner]

About this issue

This issue tracks where OpenReferral and Ohana diverge.

General

• File names are different. OpenReferral favours singular file names (e.g. Organization), Ohana favours plural file names (e.g Organizations).
• Ohana is stricter than OpenReferral in it's data model
• Ohana is stricter than OpenReferral about values like phone numbers, states and countries.
• Ohana limits the address information that can be provided, which means for long addresses in OpenReferral, information is compressed from 5 lines to 3.

Other tables

• There are similar gaps for regular_schedule and holiday_schedule: In Ohana, all fields are required but not in OpenReferral. This means a schedule in Ohana can only be provided for a specific service and location. This is not the case in OpenReferral where a schedule can be provided for a location or service.

NB: We didn't evaluate these OpenReferral tables which aren't core to converting to Ohana:

• Accessibility This is the only table that appears to be supported by Ohana
• Funding
• Eligibility
• Service_area
• Required_document
• Fee
• Payment_accepted
• Intepretation_services
• Language
• Accessibility_for_disabilities
• Metadata
• Meta_table_description

[ekoner]

Organization

• OpenReferral doesn't strictly enforce Ohana's id (The organization's unique id, starting at 1) - in OpenReferral the id is a string

• OpenReferral uses url, Ohana uses website. Ohana strictly enforces fully qualified, escaped url

• OpenReferral doesn't support:

  • accreditations (A list of accreditations an organization has received. Multiple entries must be comma-separated.)
  • date_incorporated - It uses year_incorporated meaning month and year have to be guestimated on conversion. date_incorporated formats are strictly enforced in Ohana.
  • funding_sources (A list of sources of funds for an organization. Multiple entries must be comma-separated.)
  • licenses (A list of licenses an organization has obtained to operate legally. Multiple entries must be comma-separated.)

[ekoner]

Program

• OpenReferral doesn't strictly enforce Ohana's:
  • id (The program's unique id, starting at 1.) - in OpenReferral the id is a string
  • organization_id (The ID of the organization that the program belongs to.) - in OpenReferral the organization is a string

[NeilMcKLogic]

Thanks for doing the analysis. Some systems use alphanumeric for ID's (mine does not) so the standard should be able to accommodate those, hence why it is a string and not an int.

[ekoner]

Location

• OpenReferral doesn't strictly enforce Ohana's:

  • id (The location's unique id, starting at 1.) - in OpenReferral the id is a string
  • organization_id (The ID of the organization that the program belongs to.) - in OpenReferral the organization is a string

• name is required in Ohana but optional in OpenReferral

• OpenReferral doesn't support:

  • accessibility (Accessibility options available at the location. Multiple entries must be comma-separated. See the String column in the Accessibility section for accepted values.)
  • admin_emails (Email addresses for the people allowed to administer the location (via the Ohana API Admin interface for example). Multiple entries must be comma-separated.)
  • description which is required in Ohana (Description of services provided at the location)
  • email (General Email address for the location. Emails that belong to contacts should go in the contacts.csv table.)
  • languages (Languages spoken at the location. Full language names based on the ISO 639-1 standard, such as English, French, Arabic. Multiple entries must be comma-separated.)
  • website (The location's website. The value must be a fully qualified URL that includes http:// or https://, and any special characters in the URL must be correctly escaped.)
  • virtual which is required in Ohana (Whether or not the location has a physical address. If false, it must have an address associated with it. The default value is false. Accepted values are: TRUE, FALSE, true, false, 1, or 0.)

[greggish]

cc @kinlane

Thanks, @ekoner!

[ekoner]

Service

• OpenReferral doesn't strictly enforce Ohana's:

  • id (The service's unique id, starting at 1.) - in OpenReferral the id is a string
  • location_id (The ID of the location that the service belongs to.) - in OpenReferral the location_id is a string
  • program_id (The ID of the program that the service belongs to.) - in OpenReferral the program_id is a string

• OpenReferral uses url, Ohana uses website. Ohana strictly enforces fully qualified, escaped url

• Ohana doesn't support organization_id (The identifier of the organization that provides this service.)

• OpenReferral doesn't support:

  • accepted_payments (Methods of payment for this service. Multiple entries must be comma-separated, such as "Cash, Credit Card, Medicare".)
  • description which is required in Ohana (Description of the service provided)
  • eligibility (Who is this service intended for?)
  • fees (Fees charged to receive the service)
  • funding_sources (Source of funds used to support the service. Multiple entries must be comma-separated.)
  • interpretation_services (Description of the types of interpretation services available, such as a 3-way phone call using a third party company that provides support for many languages.)
  • keywords (Keywords that people might use to search for this service, but that you might not want to include in the service description (such as common misspellings). Multiple entries must be comma-separated.)
  • languages (Languages in which this service is provided. Full language names based on the ISO 639-1 standard. Multiple entries must be comma-separated.)
  • required_documents (The documents that are required to receive this service. Multiple entries must be comma-separated.)
  • service_areas (Cities and Counties served. Multiple entries must be comma-separated. See Service Areas section for more details.)
  • taxonomy_ids (A comma-separated list of taxonomy_ids corresponding to the taxonomy you want to use. If you want to use the Open Eligibility taxonomy, refer to data/sample-csv/taxonomy.csv for a list of valid taxonomy IDs. If you are using your own taxonomy, make sure to include the CSV file that defines your taxonomy.)

[ekoner]

contact

• OpenReferral doesn't strictly enforce Ohana's:
  • id (The contact's unique id, starting at 1.) - in OpenReferral the id is a string
  • location_id (The id of the location that the contact belongs to.) - in OpenReferral the location_id is a string
  • organization_id (The id of the organization that the contact belongs to.) - in OpenReferral the organization_id is a string

[ekoner]

phone

• OpenReferral doesn't strictly enforce Ohana's:

  • id (The phone's unique id, starting at 1.) - in OpenReferral the id is a string
  • location_id (The ID of the location that the phone belongs to.) - in OpenReferral the location_id is a string
  • contact_id (The ID of the contact that the phone belongs to.) - in OpenReferral the contact_id is a string
  • organization_id (The ID of the organization that the phone belongs to.) - in OpenReferral the organization_id is a string
  • number (The 10-digit US phone number. See examples of accepted formats below.) - in OpenReferral the number is a string
  • vanity_number (The 10-digit US phone number with vanity letters. Example format: 703-555-HELP) - in OpenReferral the vanity_number is a string
  • number_type (The type that best describes the number. Must be one of these five values: fax, voice, hotline, sms, tty.) - in OpenReferral the type has two options (Whether the phone number relates to a fixed or cellular phone)

• OpenReferral doesn't support:

  • country_prefix (The country prefix code. Must only contain numbers, such as 1 for the USA.)

[ekoner]

physical_address

• OpenReferral doesn't strictly enforce Ohana's:

  • id (The unique id for the address, starting at 1.) - in OpenReferral the id is a string
  • location_id (The id of the location that the address belongs to.) - in OpenReferral the location_id is a string
  • state_province (The 2-letter capitalized US state or Canada province abbreviation, such as CA for California, or ON for Ontario.) - in OpenReferral the state_province is a string that isn't validated. This means changes are necessary to Ohana to make it usable internationally.
  • postal_code (A valid postal code. Note that the API currently assumes this will be a US 5-digit ZIP code. If you are using non-US data, you will need to replace the postal code validation with your own.) - in OpenReferral the postal_code is a string which isn't validated. This means changes are necessary to Ohana to make it usable internationally.
  • country (2-letter ISO 3361-1 country code, such as US.) - in OpenReferral the country is a string which isn't validated.

• Ohana doesn't support:

  • attention which is optional (The person or entity whose attention should be sought at the location)
  • address_3 which is optional (The third line of the address)
  • address_4 which is optional (The fourth line of the address)

NB:

• In Ohana's specification, location_id is only required if the location is not virtual - in practice, this failed to load.
• In Ohana the closest equivalent to physical_address is addresses.
• Ohana requires more information than OpenReferral does, so city, state_province, postal_code and country must all be provided.

All above apply to OpenReferral's postal_address or mail_addresses in Ohana

[ekoner]

taxonomy

In OpenReferral, a taxonomy is provided in the service table as taxonomy_ids. This is a comma separated list of identifiers from the taxonomy table.

Both tables are identical other than taxonomy_id in Ohana is named id in OpenReferral.

[timgdavies]

This informed our work in 1.1. I'm leaving open without a milestone as it may be useful for anyone working on converting from HSDS -> Ohana input prior to the API Specification being finalised.

[robredpath]

There's now an API spec that's now in use