Project: Complete UI rewrite or radiology and toolkit as an open web application

CI & CD is up, it will deploy in preview on MR on ui-rewrite branch and in production when pushed to the ui-rewrite branch.

What could be a good way to add lh-toolkit-webcomponents to the OWA? Should I just clone them and remove the .git folder and import packages from it?

@r0bby @sunbiz @judywawira

@rosekamallove no, you should not replicate the code. Just add them to the package.json, so that they can downloaded and used from npm.

When I am installing the package from the GitLab URL using yarn it is throwing errors, so I have added the missing properties from the package.json file

Please add comments, so that I can update it, once ready it can be merged. It is a blocker for me @sunbiz

The HAPI FHIR R4 test server doesn’t have radiology, what test server should I use?

LibreHealth Toolkit - Home has the following endpoints:

Please suggest another test server @sunbiz @judywawira

/radiologyxx is an internal API that’s coming from the lh-radiology module. You can assume that will still be available and non-FHIR based. You will likely have to write your own webcomponents for these API Resources. For other things, the FHIR ImagingStudy and its related FHIR resources is what you need to use.

I think this is better discussed here, rather in the MR:

The root package is not meant to be used as a whole. Separate components should be used @lh-toolkit/ and imported individually. I don’t think this change to the main repo is necessary. @rosekamallove , Can you tell me why you want to import the entire monorepo and not only the webcomponents that you need?

1 Like

The only reason for me to use the whole package was so that I can have a direct import from @lh-toolkit/package by installing it in a single npm i @lh-toolkit-webcomponents and not needing to install say 30 different packages. Which will also make the dependencies in package.json harder to manage.

Installing a single package should be an opt-in, and we should at least be able to install all the packages as one.

I think, I will for now write for ImagingStudy as it is present in HAPI FHIR, and for /radiologyxx I can work on later. It changes the GSoC proposal flow but I think it makes sense to complete bulk of the project and then come to radiology

But you will still have to import each component separately when using it on another component or web page, right? With the entire repo, you get demos, and a lot of non-essential files for distribution purposes.

If we publish it to NPM then we can ignore the non-package files in a .npmignore file, article. But I think , for now, installing packages separately is okay. I will install them separately.

This MR is for the UI Rewrite, and I will add the details tomorrow, but those details would be iterative and will update them regularly and by the end of the Re Write I will ad a Demo video.

Is there anything else that is required?

Yes, please create an issue and link the MR with that issue. If you have some designs for the UI, please add it to the issue.

1 Like

This is just a thought, it would be really good if we could add type declarations for lh-toolkit-webcomponents

Would this mean that it would work only in TypeScript and supported frameworks, and not in JavaScript ones? Can you please explain the implications of this? I don’t fully comprehend, how this might be useful.

It won’t affect the usage in a .js environment but will improve the developer experience in a .ts environment, for example when using <fhir-patient-get url={url} /> We have the following properties that can be passed

     return {
          url: { type: String },
          patientId: { type: String },
          patientName: { type: String },
          patientActive: { type: String },
          patientDecease: { type: String },
          patientBirthday: { type: String },
          patientGender: { type: String },
          patientMarriage: { type: String },
          patientContact: { type: String },
          patientAddress: { type: String },
          patientLanguage: { type: String },
          relationType: { type: String },
          value: { type: Object },
    };

In the usage, the developer would be able to see these parameters in their editor/ide through the tsserver IntelliSense, reducing bugs.

The developer using these in a .ts environment also won’t have to create a declarations.d.ts file and assign these to any instead they would be automatically seen as JSX Element

I think when we publish it to the npm registry, we should add @types/lh-toolkit-webcomponents, it is not necessary but will help the users of this library (in ts environments) a lot.

1 Like

@sunbiz Patient CRUD will be completed by the end of this week, is it possible to schedule a meeting later this week discussing the current state and the future of the project?

Patient Search → Demographics → Edit Patient is completed, please check it out and give feedback

P.S. I have finally integrated and am using lh-toolkit-webcomponents

@sunbiz @r0bby

1 Like

Yes, we can meet over LibreHealth chat and discuss this. Longer discussions that require some kind of historical perspective will be good in the forums.