Proposed project app config and fhir resource content structure

[ndegwamartin]

[project organization, e.g. lmh or sid]-[project name, e.g. ecbis or nextgen]/
|- apps/
|  |- [app name, e.g. chw or bidan]/
|  |  |- application_config.json
|  |  |- composition_config.json
|  |  |- navigation_config.json
|  |  |- sync_config.json
|  |  |- profiles/*_config.json
|  |  |- registers/*_config.json
|  |  |- translations
|  |  |  |- strings_config.properties (default)
|  |  |  |- strings_*_config.properties
|  |- (... more apps)/
|- packages/
|  |- [package name, e.g. anc or eir]/
|  |  |- library
|  |  |   |- cql/*.cql
|  |  |   |- json/*.json
|  |  |- plan_definitions/*.json
|  |  |- structure_maps
|  |  |   |- text/*.map
|  |  |   |- json/*.json
|  |  |- questionnaires/*.json
|  |  |- translations (for version control only - not used by app logic)
|  |  |   |- strings.properties
|  |  |   |- strings_*.properties
|  |- (... more packages)/

[dubdabasoduba]

@ndegwamartin I think this makes sense. I think the format might change a bit when we implement configurations reuse capabilities but we can handle that when we get there.

[pld]

yea on this note, I think we should change the structure to accommodate this now. So I'd suggest changing the fhir_content folder to just content (everything's FHIR), and then require sub-folders by module/workflow in here so content/anc then all the stuff related to the anc module is in there.

The other separate thing we need to seriously consider, is in the IG and mini-iG format what does the dir structure look like? If we can avoid making decisions here, and follow whatever that structure is, we should.

[ndegwamartin]

@dubdabasoduba could you elaborate some more on the configurations reuse?

[pld]

Following up on this after today's conversation. A couple points:

1. the validator tool will care about the structure above
2. the uploader tool may care about the structure
3. any apps pulling content from the FHIR API must not care about the structure above

I'm replacing the image above with the dir structure as I propose it, we can move it to the docs, once we get enough agreement on it

[pld]

for structuremaps do we want to use .map or .txt? we need to choose

[dubdabasoduba]

I think we can use *.map since the VSCODE extension understands the *.map file extension

[pld]

cool updated the description

[pld]

what does it mean that the fhir_content translations are for vcs only and not app logic?

[ndegwamartin]

Correct. After updating then on vcs they will be published to the server as Binary resources. They will then be utilized by the app logic after syncing down and post processing.

[pld]

hmm, ok but then aren't they used for app logic?

[pld]

feel like I'm missing something here :D

[ndegwamartin]

Sorry in my response I referenced the translation files in the app folder rather than the ones you were referring to in the packages folder (with the vcs only tag).

In the case of these, the translations are just part of the translation process. They are used for translation on Transifex and later for merging back into the Questionnaires by the tooling.

In FHIR the Questionnaires have the translations embedded within. https://build.fhir.org/languages.html

[pld]

hmm ok so you'd run the tool to generate those for transifex, then export the translated from transifex and run the tool again to update the fhir resources? makes sense

[pld]

The folder structure I added above is a pretty big change, the ID being that you have an apps folder hold sets of configs and separately reference a packages folder that holds sets of content. Then you can have each app cross reference multiple content packages, or not

[ndegwamartin]

At the root (as a sibling of project org.) we probably need to reinstate the /common folder with various content that can be shared across all the client projects/deployments @dubdabasoduba you mentioned we had such content correct? we can add some examples here.

[pld]

maybe? is the idea behind common, that we'll have common folder with a set of miscellaneous general purpose resources, and any new project app config folder that's created will need (or not need but want?) to have a copy of common and everything that's in it?

[ndegwamartin]

On the topic of environment (i.e. staging, preview, production) management, we can add some documentation on the conclusion. From the last conversation I think we wanted to explore using git tags for this.

I suppose we will then need a convention format to create the tags incrementally and across all the different projects.

Note, git tags are repo wide.

As an example, lets say we have two client projects ecbis-lib and sid-ind. Assuming we have v1.0.0 of the codebase already we would then need two different preview tags. So something like v1.0.0-preview-ecbis-lib && v1.0.0-preview-sid-ind. If we needed to make minor changes to sid-ind and push them to preview, we'd now add a new tag for sid-ind, probably v1.0.1-preview-sid-ind. This would then be repeated for all environments staging & production

It is worth highlighting that the overall objective is to at any one time be able to tell which exact snapshot of the codebase was used to deploy to a specific server instance which is useful for troubleshooting.

[pld]

I do not think we should have the env in those tags. The tags define the version of the content, but not where it happens to be deployed, like something can deploy at preview tag to stage or production, on purpose or by mistake.

If we have the IG version, we could enforce a convention, and even better use CD, so when ever you bump a version in the IG, you get a new tag for that version. When doing a config deploy you deploy from a tag. If you are looking at an env's config and what to know what's deployed there, you'd look at the version in the IG, then find the tag matching that version

[ndegwamartin]

I see. Yeah this is a better approach. I suppose regardless of what environment + project combo prompted the tweak (staging, preview or prod) any such change would always increment the IG version in this case (and create a corresponding tag).