GPS collection field/widget on Questionnaire

[ageryck]

Background:
There is a need to add a widget in the FHIR questionnaire to capture longitude, latitude, and altitude (not mandatory) on questionnaire load. Currently, the SDC does not support adding an item that can automatically pick GPS coordinates.

Proposed Approach

• Need to complete this issue as originally scoped to enable the questionnaire to pick coordinates and display them on the questionnaire, after persisting the same on the QR
• Once the above issue is completed, we need to decide how to extract the GPS details into a resource that will be usable for our foreseeable use cases

We propose this data to be extracted to a location resource and saved as follows;

• Location.identifier to hold the same id as that assigned to the Group Resources holding the household details
• Location.name to hold the same HH name
• Location.position to hold the three co-ordinates
• Location.partOf to hold Location Reference for the Practiioner's assigned Location (village)

Potential Blockers

• How to read the assigned practitioner's location to write as partOf of the newly created Location Resource

Sample Location Resource

  "resource": {
        "resourceType": "Location",
        "identifier": "52420c87-9e0b-4fb6-87ab-1e9ee1d6b5a4",
        ,
        "status": "active",
        "name": "Crispy",
        "mode": "instance",
        "type": "Building",
        "position": {
          "longitude": "36.821945",
          "latitude": "-1.292066",
          "altitude": "5492"
        }
        "partOf": {
          "reference": "Location/79cbc963-5bad-4efd-acdf-8eff2be4916a",
          "display": "Cassie Village"
        }
      }

[ndegwamartin]

For the blocker above, perhaps the questionnaire can contain a hidden field with the practitioners location and then have that extracted via SMs to the Location.partOf field

[ageryck]

@ndegwamartin I know we get this and store it during practitioner login, can we query its value via fhirpath?

[pld]

For specificity, it's not the Practitioner that is assigned to a Location, but the Location that points to the managingOrganization of the CareTeam the Practitioner is in. Is that correct?

[ageryck]

Yes, that's correct.

[dubdabasoduba]

@ageryck I think we can write a service method to get this using the rules then PREPOPULATE it to the questionnaire

[pld]

That seems useful in general, but I don't think it is required for this feature. It would be sufficient to have a StructureMap that extracts a Location from the GPS in the QR and links it to the Group (if this is a household) or the Patient (if this is a person) and uses the appropriate intermediaries of it's choice.

Whether that Location should have a partOf relationship with the Practioner's Location is an implementation decision, and I do not see that as important requirement when at analysis time you could determine that through the recorded data. An example of why I don't see this as important is that the next iteration (also out of scope for this) is likely displaying all the households (or patients) on a device in the geowidget map view, we do not need this linkage to do that.

I also think there's a reasonable argument that the Location extracted from a registration QR and is sometimes (if not often) not in a partOf relationship with the Location assigned to the Practitioner. Certainly if you're registering someone from a different catchment area, but even if not, you may not want to store this as a hierarchy, or whether you do or not might be irrelevant to you.

[dubdabasoduba]

@ageryck My assumption is that Location.identifier to hold the same id as that assigned to the Group Resources holding the household details is used to identify the location tied to the Household in question.

What if we added the Location Reference to the Group.characteristic? Here is a sample of how this would look like

{
  "resourceType": "Group",
  "id": "101",
  "identifier": [
    {
      "system": "http://someveterinarianclinic.org/fhir/NamingSystem/herds",
      "value": "12345"
    }
  ],
  "type": "person",
  "actual": true,
  "code": {
    "text": "Family"
  },
  "name": "John's Household",
  "characteristic": [
    {
      "code": {
        "coding": [
          {
            "system": "http://snomed.info/sct",
            "code": "264362003",
            "display": "Home (environment)"
          }
        ],
        "text": "Home (environment)"
      },
      "value": {
        "reference": "Location/<uuid>",
        "display": "John's Household"
      },
      "exclude": false
    }
  ]
}

[pld]

I like that approach! The other that comes to mind is pointing Group.managingEntity at a linker Org that the new Location also points to. But this seems harder to maintain because you need to create the org only for the purposes of linking

[pld]

.characteristic also seems reasonably semantically correct, since your creating a trait that's true of all the Group members

[pld]

@dubdabasoduba I think there are HL7 conversations about adding a Patient.location field, but not sure what the status is, we should check, if that's real it justifies an extension that we can migrate over in the future, vs figuring out some linker to avoid an extension

[dubdabasoduba]

@pld We also use the Group.managingEntity to reference a RelatedPerson denoting the Head of Household.

[ageryck]

Thanks @dubdabasoduba, that's a brilliant way to still link up the two resources for HH and Location, it can be our preferred way for the linkage if it also presents an easier path while querying for this data.
cc @f-odhiambo

[ageryck]

@dubdabasoduba I think there are HL7 conversations about adding a Patient.location field, but not sure what the status is, we should check, if that's real it justifies an extension that we can migrate over in the future, vs figuring out some linker to avoid an extension

@pld This would solve linkages to Patient resources much more easily and as Uganda needs this for every form/encounter we can use Encounter.location.

[pld]

Good point, we can use the location tied to the encounter on registration as a proxy for the patient location

[ageryck]

For Uganda use case to add this to all questionnaires @dubdabasoduba has some thoughts around adding this to fhircore and making it configurable to be set ON/OFF then when turned on the app auto-picks coordinates in the background and attach it as metadata to the QR. What are your thoughts on this

[pld]

I remember discussing this in the past, it's a distinct issue from what adding a gps field on Qs is, let's track in another roadmap story to start, or if there's an auditing story it can go under that, since this is more about auditing and logging than location

[joyce-x-chen]

Please confirm if I've understood correctly. There are two different use cases:

1. Capturing location of a household / school / facility in the Registration form, which is done by the user taking an action (e.g. "get GPS coordinates) and the GPS coordinates are then (a) displayed to the user and (b) saved and attached as a resource tied to the location. This can be used for service mapping and microplanning, for example.
2. Capturing locations where questionnaires are filled out, more for auditing purposes. This is done in the background, there is no UI requirement, and the GPS coordinates do not need to be displayed to the user.

Do both use cases have a dependency on the sdc or only the first?

Note that Uganda requires both of these. What is dependent on the product and what can be implemented through configs? cc: @Gental-Giant FYI the total LOE budgeted for the geowidget work was 20 software engineering days (not including scoping and QA). Is this still reasonable?

[pld]

Only the 1st depends on the SDC. The 2nd is a larger product change that hasn't been scoped. To get more accurate LOE we'd need more detailed scoping but I'd estimate 3-4 weeks per item, ie 6-8 weeks total.