Pluggable data model layer

[ir4y]

Now fhir-py uses python dicts as data model. It is nice for quick prototyping, but on later project stage, it would be nice to have a strict type definitions like https://github.com/Aidbox/aidbox-python/tree/main/aidbox/resource or https://github.com/beda-software/fhir-py-types

AsyncFHIRClient and FHIRClient should get a data constructor attribute that will be used to instantiate instance of the fhir resources

[ruscoder]

I propose a solution to tweak entry points .resource/.resources with the first argument as a model class (pydantic), e.g.

client.resources(Patient)  # AsyncFHIRSearchSet[Patient]
client.resources(Patient).fetch()  # list[Patient]

It's fully backward compatible with str-types:

client.resources('Patient')  # AsyncFHIRSearchSet[AsyncFHIRResource]
client.resources('Patient').fetch()  # list[AsyncFHIRResource]

[ruscoder]

Within this task I've added typehints for all methods that we have in the project and installed mypy typechecker

[ruscoder]

After introducing this task we should have an API on client level to work with these resources, I propose:

client.save(resource: T, fields: list | None = None) -> T: ...
client.create(resource: T) -> T: ...
client.update(resource: T) -> T: ...
client.patch(resource_type: type[T] | str, id: str, **kwargs) -> T: ...
client.patch(resource: T | str, **kwargs) -> T: ...
client.delete(resource_type:  type[T] | str, id: str): ...
client.delete(resource: T | str, id: str): ...

and reuse these functions in our BaseResource implementation.

For conditional operations, SearchSet should have operations:

searchset[T].get_or_create(resource: T) -> T: ...
searchset[T].update(resource: T) -> T: ...
searchset[T].patch(**kwargs) -> T: ...
searchset[T].delete(): ...

[ruscoder]

Documentation (README) needs to be updated

[ruscoder]

The task is completed, README is updated.