We have a service record from an Open Referral UK API that fails validation because it has no postcode. The service in question has a service_at_locations.name of “In the client’s home or outside in a park”.
How should we publish such data?
So I suspect this is a matter of distinguishing the point of service enrollment from the mode of service delivery.
where does the client sign up for the service? Over the phone? At a website? Assuming there is a point of contact for enrollment, that might be the service location.
Then the mode of service delivery is a known use case for attributes but I think there have been some recent interesting discussions about how to manage “service modality” or “service delivery type” via attributes so maybe we can weave those discussions in here.
1 Like
That makes sense Greg. @iansingo do you think so. If so, might the data you have recently published be amended accordingly? We can talk offline about specific record(s) if necessary.
Happy to chat about what data you want in which field but we use an attribute to indicate where the service is delivered e.g. home visit, app, phone, venue, doc, online.
My main question for ORUK is is “should which field holds what data and which attributes are used be open to interpretation? Surely it would be easier for people to re-use the data if it was clear what they were getting and where.”
I originally thought an ‘application profile’ would explain this to any consumer but I am just not sure.
Generally speaking, my sense is that “which field holds what data” should not typically be open to interpretation, but “which attributes are used” sometimes will have to be. There may be an issue like this for which Open Referral could offer “non-normative” guidance for use of the attributes table, and a local network like ORUK could make more formal decisions in their profile.
I agree Greg and I am saying this is an ORUK issue rather than an international issue. There is a bit of room for interpretation on ORUK fields and further space with the ability to extend and ignore fields.
I accept that taxonomies are more difficult to control but again my hope is that an ORUK profile might give some basics that will enable consumers to make use of the data. Most of the ability to match a resident/patients needs to a service come from the attributes. Without these the data consumers are going to struggle.
I will discuss with @MikeThacker offline