Re: Feed back loops discusion

[AtticusRains]

From conversations being had in the Slack channel, there seems to be quite a bit of interest in creating feedback mechanisms. I took a crack at seeing what that would look like in HSDS taking inspiration from the metadata table.

Field Name	Type	Required
id	String	True
resource_id	String	True
metadata_id	String	True
field_name	String	True
current_value	String	True
suggested_value	String	False
source	String	False

I would love to hear what others are doing in this regard.

[epompeii]

I have a fully functioning revisions table with these attributes. Let me know if you would like to take it for spin. There's also some additinal complexity in how a revion is created (not in the model) to handle things like default and nullable values.

Field Name	Type	Required
id	int	True
requester_id	int	True
org_id	int	True
table	string	True
base (table)	string	False
column	string	True
row_id	int	True
parent_id	int	False
value	string	True
type	string	True
requested	datetime	True
updated	datetime	False
status_id	int	True
approver_id	int	False
current	bool	True
permissions	int	True

[greggish]

I'm very interested to hear from others about how they're handling feedback and verification. Part of my my gut says that a lot of functions are going to be very context-specific, and another part of my gut says that some of these functions might not even exist in the field yet as feedback mechanisms to date have been pretty unstructured...

That said, I do think we should start thinking about which parts of the feedback loop can be specified, so these examples are great to see...

[NeilMcKLogic]

Can you please explain what you mean when you say "feedback"? What is the use case being addressed here? I'm interested.

[AtticusRains]

Hi Neil, @greggish might have a better explanation, but the use case that I am targeting here is the ability for users to flag a field as being incorrect and optionally suggest a new value.

[epompeii]

@NeilMcKechnie doing so accomplishes two things: 1) It allows for "track changes" or a wiki-like history for listings edits 2) A request -> review -> approve (or reject) workflow The idea is that this should lead to a more collaborative resource directory.

[ldsalomone]

I came across the following article and am contributing it here in case anyone finds it valuable for this issue. http://db.ucsd.edu/static/ricolla/pubs/conflict_resolution.pdf

Feb 2021 edit: The above link is now dead 😞

[greggish]

I came across the following article and am contributing it here in case anyone finds it valuable for this issue. http://db.ucsd.edu/static/ricolla/pubs/conflict_resolution.pdf

Feb 2021 edit: The above link is now dead 😞

Is this the same paper? https://cseweb.ucsd.edu/~ikatsis/publications/icde10demo.pdf Or this? https://cseweb.ucsd.edu//~ikatsis/publications/techreport.pdf @ldsalomone

[greggish]

The FHIR documentation for healthcare provider directory validation is worth considering: http://build.fhir.org/ig/HL7/VhDir/technical-guidance.html#validation

Notably, at the end of this page: The FHIR specification does not provide guidance on managing common elements across resources to reduce redundancy or ambiguity. Likewise, this implementation guide does not provide additional guidance. Implementations should consider further constraining profiles, creating invariants, or requiring data sources (e.g. attesters) to contribute data in a consistent format. Some resources include elements for describing exceptions, such as the availabilityExceptions field on HealthcareService, Location, and PractitionerRole. Additionally, validation processes may help discover and address inconsistencies across resources.