We're only gonna do this once... This PR addresses some style inconsistencies in our library and moves files around a bit. It's purely for readability and aesthetic choices, but I'd rather we do it earlier rather than later.
Refactoring changes
Moved Workflow and its associated use case utility functions from base.py -> workflow.py. As this is something the user interacts with it makes sense to have it in a more descriptive separate module.
Moved client.py to clients/ehrclient.py to distinguish between potential different client modules.
Moved the ehr decorator to clients/ehrclient.py. Functionally, it makes more sense for this decorator to be located in the same file as the client function. I have trouble finding where it is myself sometimes lol.
Moved Endpoints from utils/ to service/ - same reasoning as above
Moved APIMethod from utils/ to use_cases/ - ditto (it's a bit confusing as they are synonyms for each other, but one is to wrap it for the server and the other is to define it for a certain use case schema - hence it makes more sense to move them closer to where they're used).
Renamed datagenerator.py to cdsdatagenerator.py to keep the filename consistent with the class name.
Renamed folder data_generator to data_generators - yeah, I know this is nitpicky, but as our current data generator is quite tightly coupled to CDS, we might add different generators in the future that users can import from the data_generators module
Tidied all __init__.py files for a consistent API.
Styling changes
Folder names should be all lower case letters with underscores e.g. data_generator
File names should be all lower case letters with no underscores or dashes in them, e.g. datagenerator.py instead of data_generator.py - as we have some long filenames I think brevity looks better with import statements.
For the above reason I also dropped the resource suffix in files under fhir_resource as it ends up being a very long name.
Class names should be camel case with no underscore in it e.g. BundleEntry.
Pydantic models should be descriptively named without the explicit word Model in it.
As a result all fhir resources are renamed in this convention e.g. Bundle_EntryModel -> BundleEntry.
I also needed to rename some resources to avoid clashes e.g. Coding is also a data model in Cds hooks, which is apparently a simple version of the Fhir resource Coding with the same name (why would they do this??) - so it's renamed SimpleCoding.
Likewise with Extension in data_generator/value_sets/codingsystems.py -> renamed to CodingExtension.
As a general rule I think priority should be given to OG FHIR resources.
Acronyms in class names: use all capitals for acronyms if it is the only acronym and it is the first word. e.g. FHIRAuthorization, CDSRequest. Only capitalise the first letter if there is more than one acronym in the class name e.g. CdsFhirData.
Imports: use absolute imports for any import that is not at the same directory level as the file.
GOOD: from healthchain.data_generators import cdsdatagenerator, from .workflow import Workflow
BAD: from ..base import BaseUseCase , from .client.ehrclient import ehr
We're only gonna do this once... This PR addresses some style inconsistencies in our library and moves files around a bit. It's purely for readability and aesthetic choices, but I'd rather we do it earlier rather than later.
Refactoring changes
Workflowand its associated use case utility functions frombase.py->workflow.py. As this is something the user interacts with it makes sense to have it in a more descriptive separate module.client.pytoclients/ehrclient.pyto distinguish between potential different client modules.ehrdecorator toclients/ehrclient.py. Functionally, it makes more sense for this decorator to be located in the same file as the client function. I have trouble finding where it is myself sometimes lol.Endpointsfromutils/toservice/- same reasoning as aboveAPIMethodfromutils/touse_cases/- ditto (it's a bit confusing as they are synonyms for each other, but one is to wrap it for the server and the other is to define it for a certain use case schema - hence it makes more sense to move them closer to where they're used).datagenerator.pytocdsdatagenerator.pyto keep the filename consistent with the class name.data_generatortodata_generators- yeah, I know this is nitpicky, but as our current data generator is quite tightly coupled to CDS, we might add different generators in the future that users can import from thedata_generatorsmodule__init__.pyfiles for a consistent API.Styling changes
data_generatordatagenerator.pyinstead ofdata_generator.py- as we have some long filenames I think brevity looks better with import statements.resourcesuffix in files underfhir_resourceas it ends up being a very long name.BundleEntry.Modelin it.Bundle_EntryModel->BundleEntry.Codingis also a data model in Cds hooks, which is apparently a simple version of the Fhir resourceCodingwith the same name (why would they do this??) - so it's renamedSimpleCoding.Extensionindata_generator/value_sets/codingsystems.py-> renamed toCodingExtension.FHIRAuthorization,CDSRequest. Only capitalise the first letter if there is more than one acronym in the class name e.g.CdsFhirData.from healthchain.data_generators import cdsdatagenerator,from .workflow import Workflowfrom ..base import BaseUseCase,from .client.ehrclient import ehr