hapifhir
Feature Request: Provide an implementation of BaseIdentifierDt in hapi-fhir-structures-r4 et al
The HAPI FHIR client has support for searching for a resource based on a list of identifiers.
Simplified example:
fun practitionersByIdentifiers(identifiers: List<BaseIdentifierDt>): Bundle {
val client = FhirContext.forR4Cached().newRestfulGenericClient("http://example.com")
return client
.search<Bundle>()
.forResource(Practitioner::class.java)
.where(Practitioner.IDENTIFIER.exactly().identifiers(identifiers))
.execute()
}
The client's .where(Practitioner.IDENTIFIER.exactly().identifiers(...)) method expects an input list of of abstract class BaseIdentifierDt (from hapi-fhir-base).
The problem is there is no implementation of BaseIdentifierDt in hapi-fhir-structures-r4 (and the other datastructure artifacts).
There is only one in hapi-fhir-structures-dstu2, called IdentifierDt.
Is this an oversight?
Yeah honestly...we should probably use CanonicalIdentifier there instead, despite the fact that that is a HAPI-FHIR class and not a core class. Looks to me as though as of STU3 onwards, we don't use the BaseIdentifierDt at all, and instead just use Identifier which is an ICompositeType.
Looks to me as though CanonicalIdentifier is a BaseIdentifierDt. Can you just construct some canonical identifiers and use those?
To me it looks like CanonicalIdentifier is not in the hapi-fhir-client or hapi-fhir-structures-r4 Maven artifacts or one of their transitive dependencies, so I cannot import it.
From the looks of it, CaninicalIdentifier is in hapi-fhir-storage which does not seem to be a transitive dependencies of the client or structures-r4.
Yeah totally fair. FWIW you can subclass BaseIdentifierDt and use it for your own needs.
IMO the solution is to eventually fix the data model hierarchy so that the client can support DSTU3+ Identifier objects as well as DSTU2 BaseIdentifierDts. An alternative solution is to implement another identifiers() method which just supports the other versions of the identifiers, but that's a bit clunkier. Changing the data model to make a parent Identifier type is probably the right solution, but its more of a heavy lift with implications across other pieces (specifically the core libs).
