Commure's experimental implementation of the populate-and-extract flow for SDC lacks some functionality, and some Parameters on the
$populate extended operations that are present in the FHIR specification may be unimplemented. This page describes some of these limitations, and recommended workarounds.
Extracting multiple resources that reference each other
If you write a Questionnaire that extracts multiple resources, there is no way to encode, in that Questionnaire's items, a reference to one resource in the field of the other.
For example, if you wrote a Questionnaire for collecting insurance information that extracts both an Account and a Coverage, Commure's implementation does not offer a way to indicate in the extraction of Account that
Account.coverage.coverage should be a reference to
newly-created-coverage-id does not yet have an ID, you cannot reference a yet-to-be-created resource.
The workaround for this is to "link" your resources in a post-extraction step, on your client-side code. For the above example, when you've received the results of
$extract (i.e. you are given a POST-able Bundle with an Account and a Coverage), you can set
Account.coverage.coverage to be something like
Bundle.entry.where(resource.resourceType = 'Coverage').fullUrl, where
fullUrl will then correctly resolve to the newly-created Coverage resource.
$extract implementation has limited support for Questionnaire
repeats=true. It may work correctly in some cases, but extensions like
sdc-named-context may have unexpected behavior in attempting to extract multiple resources of the same named context.
There is no perfect workaround here, except to hardcode
1..* instances of groups that you want to be "repeatable," perhaps chained by
enableWhen logic to simulate the experience of having an arbitrary number of entries.
canonical parameter on $populate
The input parameter
$populate is unimplemented. Please use one of the alternatives —
questionnaireRef — to pass in the Questionnaire to be used.