Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing RM-Mappings support #56

Open
owenfar opened this issue Jan 29, 2024 · 2 comments
Open

Missing RM-Mappings support #56

owenfar opened this issue Jan 29, 2024 · 2 comments

Comments

@owenfar
Copy link

owenfar commented Jan 29, 2024

Hello,

Currently the library does not support some RM types such as DV_IDENTIFIER, DV_URI, SECTION, ... I don't know if I'll face more clashes but I'm wondering if the library is being maintained / up-to-date with latest changes in data types found in EHR templates & archetypes?

Another thing I want to point out is multi-lingual support. Templates can be exported in multiple language types, currently I think the library only defaults to EN (at least from the VSCode extension side of things).

Thanks in advance

@sidharthramesh
Copy link
Collaborator

Hey @owenfar, it is true that we currently don't support all DV types - DV_IDENTIFIER and DV_URI included. However, you can use <mb-context> or <mb-input> along with these RM types in most cases depending on your use case - all of the rest of the form components will still work.

Regarding SECTION - it's more of a structural data structure, with usually leaf nodes underneath. Medblocks UI does not deal with such RM types. We only deal with the end-left input nodes.

Regarding multi-lingual support - since the output artefact of Medblocks UI is a set of web components with predefined labels, it would be challenging to add multiple languages to the workflow, without <mb-form> depending on the web template. However, if you can directly take the labels from the web template, then I think you should be able to use an i18n library and dynamically pull the labels based on the language selected. I would like to hear ideas on other way we could support this multilingual workflow.

Medblocks UI is still maintained, and we provide regular updates based on the needs of our users. Happy to see you're considering this 😄. Any input or feedback is appreciated!

@owenfar
Copy link
Author

owenfar commented Jan 30, 2024

Hello @sidharthramesh, thank you for your reply. I'm glad to hear it's still maintained because it's the best library available at the moment and we're considering to use it in production in the near future.

Do you see DV_IDENTIFIER more as an <mb-context> from your point of view? I checked the docs here and I'm not sure whether I need an input for the ID, but some templates do seem to request the ID to be submitted although it's not very clear.

For DV_URI and DV_EHR_URI I used the <mb-input>. And for SECTION, I'm guessing I can leave it empty then :)

Thanks once again for these suggestions.

In terms of languages, for our use-case I updated the transformations object functions to include a second parameter called lang example:

DV_COUNT: (n, lang) => [
    {
        name: 'Count',
        html: `<mb-count path="${n.path}" label="${(n.localizedNames) ? n.localizedNames[lang] || n.name || '' : n.name || ''}"></mb-count>`,
     },
],

This way if the language is available, we can output the right language context.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants