32 document registry #121

clemens-msupply · 2022-06-13T21:24:27Z

Also includes some refactoring to use the existing form_schema table for json_schema and ui_schema.

The document registry has an entry for every document type describing:

in what context it is used (Patient, Program, Encounter)
what the schemas are
what the relation to other documents are (currently only parent, e.g ABCEncounter -> ABCProgram)

Closes #32

andreievg

I had a quick look, will look at it more thoroughly, but had some question before.
Also, when ui/json schema is updated how do we record it and query for latest document type schema ?

andreievg · 2022-06-15T00:48:43Z

server/graphql/document/src/lib.rs

-use mutations::insert_json_schema::insert_json_schema;
-use mutations::insert_json_schema::InsertJsonSchemaInput;
-use mutations::insert_json_schema::InsertJsonSchemaResponse;
+use mutations::insert_document_registry::insert_document_registry;


I just realised this is quite different to how we use modules in other graphql crates. I guess the file structure is different.

Any reason to not just insert_document_registry::* ?

Btw are you using cmd/ctrl + . to import or importing manually ? (usually cmd/ctrl + . would add to existing use clauses)

You mean the duplicated use mutations::insert_document_registry::...? I usually use the VSCode import and usually it works as you said. Not sure how this happened...

Regarding the file structure, its currently a bit messy but I plan clean it up and use some more logical structuring...

andreievg · 2022-06-15T00:58:25Z

server/graphql/document/src/mutations/insert_document_registry.rs

+use crate::types::document_registry::{DocumentRegistryNode, DocumentRegistryNodeContext};
+
+#[derive(InputObject)]
+pub struct InsertDocumentRegistryInput {


Is this for development ? All settings related to programs are centrally controlled

Yes, might have overdone it but need a way to insert new registry entries.

andreievg · 2022-06-15T01:00:53Z

server/repository/migrations/postgres/2022-06-07T15-00_create_document_registry/up.sql

@@ -0,0 +1,15 @@
+CREATE TYPE document_context AS ENUM (
+    'PATIENT',
+    'PROGRAM',


Shouldn't programs have a seperate table ? It's a different 'thing' to to documents, and doesn't have parent_id or document_type or document_context or form_schema-id.

In the program document patient specific data for a program is stored, e.g. family history, or if the patient is in a risc group. This information can in general change over time. Every patient can only have one program of each kind, i.e. you can't be enrolled in the same program twice.

ok I dont' quite understand how this works (i did look at the issue).

What would data look like for this scenario:

two programs, 'HIV' and 'TB'.

HIV -> has document type 'Encounter A' (with two versions of ui schema and json schema)
TB -> has document type 'Encounter B' (just with one version)

There is a base 'Patient' document type (not linked to any program, for patient data entry for stores with no programs), with two versions of ui schema and json schema

One common 'Patient' document type to be used for both TB and HIV

By two versions btw I mean customer has added new fields to the form.

For the example, there is no document_versions yet, just the config

Is your question how to manage multiple schema versions? e.g. what happens if an older document version has a different schema?

The registry describes what schemas should be used for new document updates, e.g. when creating or updating a document.
If there is an existing document that already uses an old schema version, the old schema id is recorded in the document.

The central json schemas should be immutable, i.e. when the a schema is update the registry entry needs to be updated to point to this new schema. For ui schema its probably fine/desirable to always show the latest UI as specified in the registry.

A patient could have the following docs:

patients/patient1 (type: Patient, context: Patient)
patients/patient1/programs/HIVProgram (type: HIVProgram, context: Program)
patients/patient1/programs/HIVProgram/encounters/EncounterA_1 (type: EncounterA, context: Encounter)
patients/patient1/programs/HIVProgram/encounters/EncounterA_2 (type: EncounterA, context: Encounter)
patients/patient1/programs/TBProgram (type: TBProgram, context: Program)
patients/patient1/programs/TBProgram/encounters/EncounterB_1 (type; EncounterB, context: Encounter)

Some initial questions:

why do you need a programs table? A program is just a special kind of document. If you want to add a program you can just add an entry to the document_registry table (programs have schemas as well).

why version? when would you use this? or is it just for completeness?

what do you mean by is_tracker?

Could you please give me your motivation behind these schemas than I can explain how it works with mine.

Ohh man, i delete a comment I shouldn't have, i wrote one listing requirements then another one that started with I reverted a comment (and deleted both by accident), I am wondering if you can see the last one in your email (the one starting with i reverted a comment ? Can you paste it in if it's there ?

If you don't find the comment, I'll re-write it. I think atm I am leaning towards:

program

id name

1 General

2 HIV

3 TB

document_type

id name version form_schema_id is_encounter (or is_tracker)

1 Patient 1 1 false

2 Patient 2 2 false

3 Encounter A 1 3 true

4 Encounter A 2 4 true

5 Encounter B 1 5 true

document_type_program_join

id program_id document_type_id

1 1 1

2 1 2

3 2 2

4 2 3

5 2 4

6 3 1

7 3 6

Accidentally deleted comment from Andrei:

I reverted a comment, just in case you've seen it in email notifications.

why do you need a programs table Program (HIV, TB, Malaria) is a broader functionality, and is used in other areas, including our speciality the supply chain (they are the 'same thing' in terms of reporting, and it's one area where HIS and supply chain data meet). So to me, they are not related to documents but as their own entity to which documents belong. It doesn't sound like we have a requirement to link document types with other types in hierarchy, so it seems parent_id only use is to link encounters to programs (would encounters ever be linked to other encounters ? if so can you give example from requirements) A program is just a special kind of document As per above, in terms of full context, programs are beyond document. why version? when would you use this? or is it just for completeness? Since form and json schema can change for a document_type (it's customisable), for some reason I assumed the previous schema needs to be records. On second thought the only immediate use case I can see of this is for user to look at historic schemas to re-introduce something. So not sure if it's needed. what do you mean by is_tracker I thought there were two types of forms, one time with multiple edits (i.e. patient) and tracker which is HIS term for repeating data point, which is encounter in our case. Could you please give me your motivation behind these schemas than I can explain how it works with mine.

Basically the above. I realise my example is not great, especially One common 'Patient' document type to be used for both TB and HIV <- i think in country, we would always just have one Patient document type, and program related document are extras. i.e. when looking at program view in UI for a particular patient, base Patient document type is present in one form, any extra non tracker forms for the program and any extra tracker forms for the program.

Thank you, i have something else to add, but I'll do it in the issue

andreievg · 2022-06-17T00:28:58Z

server/graphql/document/src/types/document_registry.rs

+}
+
+#[Object]
+impl DocumentRegistryNode {


I think we want to present front end with everything that's needed to enter and save data, not sure how this would look like, but would assume something like:

PatientNode {
document: DocumentAndSchemaNode,
programs: PatientProgramNode
}

PatientProgramNode {
programName
documents: DocumentAndSchemaNodeConnector
}

thoughts ?

I would also assume there would be something like newPatientDocuments, with something similar

Yes agree would be good to have an endpoint to fetch patient documents like this. What would be newPatientDocument?

I added #136

Like if there is no PatientNode, and you want to create new patient, API can provide all of the schemas needed for that patient in one go (based on user permissions for the programs). I guess you can look up document registry for this ?

andreievg

Thanks.

I'll relocate the schema discussion to an issue, and I also think we need to look at UI elements and see what API is needed to make them work (with minimum logic done by front end).

Also for inserts of central data, I think for the future we should just hard code them in sync (similar to what we did for name_store_joins at the start, when we wanted to use them but remote sync was not implemented).

This would also allow ease of sharing configurations between b/e and f/e (don't need to pass along sql/graphql statements etc..)

clemens-msupply · 2022-06-17T01:53:02Z

Thanks.

I'll relocate the schema discussion to an issue, and I also think we need to look at UI elements and see what API is needed to make them work (with minimum logic done by front end).

Also for inserts of central data, I think for the future we should just hard code them in sync (similar to what we did for name_store_joins at the start, when we wanted to use them but remote sync was not implemented).
* This would also allow ease of sharing configurations between b/e and f/e (don't need to pass along sql/graphql statements etc..)

I was thinking in the line as well. Using graphql endpoints just for devs is a bit too much work...

czeidler added 8 commits June 13, 2022 14:26

Morph json_schema table to the existing form_schema mSupply table

e0d9b01

Rename FormSchemaRow

630f5a2

Add document registry repositories

56e8b02

Rename FormSchemaRepository to FormSchemaRowRepository

d4802b5

Add document registry service

0e2fabb

Refactor form_schema naming

66b065e

Add document registry endpoints + refactoring

9ef419c

Add document registry insert test

937ae02

andreievg reviewed Jun 15, 2022

View reviewed changes

Clean up imports

e8a2140

andreievg reviewed Jun 17, 2022

View reviewed changes

andreievg approved these changes Jun 17, 2022

View reviewed changes

Merge branch 'feature/programs' into 32-document-registry

11f042a

clemens-msupply merged commit 7806f59 into feature/programs Jun 17, 2022

clemens-msupply deleted the 32-document-registry branch June 17, 2022 02:05

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

32 document registry #121

32 document registry #121

clemens-msupply commented Jun 13, 2022 •

edited

Loading

andreievg left a comment

andreievg Jun 15, 2022

clemens-msupply Jun 15, 2022

andreievg Jun 15, 2022

clemens-msupply Jun 15, 2022

andreievg Jun 15, 2022

clemens-msupply Jun 15, 2022

andreievg Jun 15, 2022 •

edited

Loading

andreievg Jun 15, 2022 •

edited

Loading

clemens-msupply Jun 15, 2022

clemens-msupply Jun 16, 2022

andreievg Jun 16, 2022 •

edited

Loading

andreievg Jun 16, 2022

clemens-msupply Jun 16, 2022

andreievg Jun 16, 2022

andreievg Jun 17, 2022

andreievg Jun 17, 2022

clemens-msupply Jun 17, 2022

clemens-msupply Jun 17, 2022

andreievg Jun 17, 2022

andreievg left a comment

clemens-msupply commented Jun 17, 2022

id	name	version	form_schema_id	is_encounter (or is_tracker)
1	Patient	1	1	false
2	Patient	2	2	false
3	Encounter A	1	3	true
4	Encounter A	2	4	true
5	Encounter B	1	5	true

32 document registry #121

32 document registry #121

Conversation

clemens-msupply commented Jun 13, 2022 • edited Loading

andreievg left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andreievg Jun 15, 2022 • edited Loading

Choose a reason for hiding this comment

andreievg Jun 15, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andreievg Jun 16, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andreievg left a comment

Choose a reason for hiding this comment

clemens-msupply commented Jun 17, 2022

clemens-msupply commented Jun 13, 2022 •

edited

Loading

andreievg Jun 15, 2022 •

edited

Loading

andreievg Jun 15, 2022 •

edited

Loading

andreievg Jun 16, 2022 •

edited

Loading