Open liberaliscomputing opened 4 years ago
I edited the above (this isn't related to the ncpi fhir util). I'm relieved that the scenario could be handled by a more adaptive submit method, but I think that remodeling PatientRelation as a separate profile might be a more correct approach so that multiple passes aren't needed. I guess it depends on whether there's any negative performance impact when querying if the relationships are on a separate resource.
@znatty22 and I talked about this, and we think that we may be able to use Observation for this.
subject = PT1 focus = PT2 code = something like "family relationship" valueCodeableConcept or valueString = something like "Mother"/"Father"/etc
The only thing is that the focus field is marked as "Trial Use"
The following is an example payload as discussed above:
{
"resourceType": "Observation",
"id": "fr-001",
"meta": {
"profile": [
"http://fhir.kids-first.io/StructureDefinition/kfdrc-family-relationship"
]
},
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "35359004",
"display": "Family"
}
]
},
"subject": {
"reference": "Patient/pt-001" # Assume this is a mother
},
"focus": [
{
"reference": "Patient/pt-002" # Assume this is a child
}
],
"valueCodeableConcept": {
"coding": [
{
"code": "PRN",
"display": "parent",
"system": "http://terminology.hl7.org/CodeSystem/v3-RoleCode"
},
{
"code": "MTH",
"display": "mother",
"system": "http://terminology.hl7.org/CodeSystem/v3-RoleCode"
}
],
"text": "Mother"
}
}
This way, we can run a target api builder row by row against the family_relationship
table.
Here is the NCPI discussion thread: https://github.com/ncpi-fhir/ncpi-model-forge/issues/21
This PR raised one caveat of our PatientRelation extension: Since it is an extension to Patient and all the reference patients should already be created, we always have to run two passes, one for patients and the other one for updating patient relations in patients.
We can address this by adding a capability for a selection of HTTP request methods to the submit routine. Or, we can re-model PatientRelation as a separate profile as we ingest
'family_relationship'
separately with the KF ingest library.