Nested facility service data about vets-api HOT 8 CLOSED

Yes, absolutely on both returning the hierarchy and only including the present services. My suggestion is something like this:

...
"Services": {
  "PrimaryCare": [],
  "Rehabilitation": [],
  "MentalHealthCare": ["OutpatientMHCare", "OutpatientSpecMHCare"]
}
...

I.e. SL1 services are indicated by presence as keys in the overall "Services" dict. SL2 services are indicated by presence in the list that you get back from their parent SL1 key. SL1 services that don't have any sub-services have an empty list, but are still available as a top-level service.

It's a little awkward mixing dicts and lists, but it avoids the redundant "true" values for the SL2 services. And while I like the idea of the backend owning/returning the display names, I don't want to repeat that information on each and every record. I'd rather have a separate metadata endpoint where we can serve the hierarchy info statically; frontend apps can retrieve it once and cache it.

from vets-api.

You're probably also saying, well which services are nested under what?! Here is a list:

Audiology
ComplementaryAlternativeMed
DentalServices
DiagnosticServices
    ImagingAndRadiology
    LabServices
EmergencyDept
EyeCare
MentalHealthCare
    OutpatientMHCare
    OutpatientSpecMHCare
    VocationalAssistance
OutpatientMedicalSpecialty
    AllergyAndImmunology
    CardiologyCareServices
    DermatologyCareServices
    Diabetes
    Dialysis
    Endocrinology
    Gastroenterology
    Hematology
    InfectiousDisease
    InternalMedicine
    Nephrology
    Neurology
    Oncology
    PulmonaryRespiratoryDisease
    Rheumatology
    SleepMedicine
OutpatientSurgicalSpecialty
    CardiacSurgery
    ColoRectalSurgery
    ENT
    GeneralSurgery
    Gynecology
    Neurosurgery
    Orthopedics
    PainManagement
    PlasticSurgery
    Podiatry
    ThoracicSurgery
    Urology
    VascularSurgery
PrimaryCare
Rehabilitation
UrgentCare
WellnessAndPreventativeCare

We would have to build this logic manually into the API I'm thinking...

from vets-api.

re: 1) In the front-end, it would be nice to have the keys nested and the nesting logic built into the API. It's probably better to have the service hierarchy in the backend instead of frontend.

re: 2), only including services that are available saves us from having to iterate over the entire response. As an added bonus, maybe we could use the value field to store a formatted display name so that the names are more descriptive, ie

"MentalHealthCare": {
  "OutpatientMHCare": "Outpatient Mental Health Care",
  "OutpatientSpecMHCare": "Outpatient Specialized Mental Health Care",
}

from vets-api.

Representing the L1 services as keys in a dict makes things awkward because the keys get treated as keys from the JSON API perspective and get munged by Olive Branch, but the values do not. So now proposing to make the services a big nested list so it just gets treated as data:

[
  ["Audiology",[]],
  ["DentalServices",[]],
  ["DiagnosticServices",["ImagingAndRadiology"]],
  ["EyeCare",[]],
  ["MentalHealthCare",["OutpatientMHCare","OutpatientSpecMHCare","VocationalAssistance"]],
  ["OutpatientSurgicalSpecialty",["Podiatry"]],
  ["PrimaryCare",[]],
  ["Rehabilitation",[]],
  ["WellnessAndPreventativeCare",[]]
]

Overall list of services is a list of tuples, first element being an SL1 service, second element being a list of SL2 services (or an empty list).

from vets-api.

What about something like this:

[
    {
        "L1": "Audiology",
        "L2": []
    },
    {
        "L1": "DentalServices",
        "L2": []
    },
    {
        "L1": "DiagnosticServices",
        "L2": [
            "ImagingAndRadiology"
        ]
    },
    {
        "L1": "EyeCare",
        "L2": []
    },
    {
        "L1": "MentalHealthCare",
        "L2": [
            "OutpatientMHCare",
            "OutpatientSpecMHCare",
            "VocationalAssistance"
        ]
    },
    {
        "L1": "OutpatientSurgicalSpecialty",
        "L2": [
            "Podiatry"
        ]
    },
    {
        "L1": "PrimaryCare",
        "L2": []
    },
    {
        "L1": "Rehabilitation",
        "L2": []
    },
    {
        "L1": "WellnessAndPreventativeCare",
        "L2": []
    }
]

from vets-api.

@carlmjohnson Yeah, I like that better, having the L1/L2 keys gives some indication of the semantics.

from vets-api.

^ that structure LGTM

from vets-api.

Works well with olive branch so I'm going to say that's decided. See #134 for full record format description.

from vets-api.