This would truly be a game changer for health care if JSONForms could generate all the forms to this schema. Thanks in advance for the support. I will send a sponsorship if this can work.
“rather large” is quite some euphemism when describing a ~4 MB JSON Schema file
The JSON Forms React seed is not using the latest prerelease of JSON Forms which had some resolving improvements. When using JSON Forms 3.0.0-rc.0, some UI is rendered. However it’s certainly not ideal.
I had a look through the JSON Schema. In general it’s relatively simple but of course it’s very large. The default combinator renderers (oneOf/allOf/anyOf) are also pretty basic and therefore unsuited for the use cases here.
There also seem to be some domain-specific “extension” patterns in there, e.g.
"purpose": {
"description": "Explanation of why this operation definition is needed and why it has been designed as it has.",
"$ref": "#/definitions/markdown"
},
"_purpose": {
"description": "Extensions for purpose",
"$ref": "#/definitions/Element"
},
For these you very likely want some UI customizations to render these nicely.
It’s worth considering to not render a single form for this whole schema but using some more sophisticated approach. The schema seems to contain many nested arrays. So some sort of tree editor might be a good fit. The “detail” component of the tree editor could then be rendered via JSON Forms.
If you further want to go down the route of rendering this within a single JSON Forms based form I would recommend implementing a custom oneOf renderer. That one could for example render a nice dropdown to select an option instead of 100+ Tabs.
@sdirix Thanks so much for looking into it. I cant make it compile with 3.0.0-rc.0 using the react seed project. I tried messing with the dependencies, but the whole thing kind of fell apart on me. Do you have the working code somewhere I can see it , or can you pr the seed project?
Like I said this would be amazing if we could have a data driven forms based ui for FHIR using this tech. Everyone is going to Material UI design so we want to keep that in play. I agree on the tree editor. FHIR has 127 resources as you can see why efforts like this GitHub - healthintellect/fhir-ui: React components for displaying HL7 FHIR data using Material-UI that don’t leverage the schema cannot scale. Things get even more complicated when you get to required fields, data validation, and references from one piece of data to another. Also localization/internationalization is an issue that can only be solved with a schema driven solution. Same with new versions of the spec, and some of the unique things in fhir like resource profiling. Also, the form needs to produce valid FHIR when the user saves them. So it is imperative that we use a data driven approach.
FHIR is the International standard for health care. This is an open source project that benefits every human being on the planet because you will be able to write your own health record as well as read in records from other sources. FHIR does also have all of its data types in individual json files called StructureDefinitions that have richer metadata that the schema. So those are in play too. As are FHIR ValueSets, CodeMap, CodeSystems, etc. Anyone who would like to help engineer this would be welcome. Let me know and Ill give you a link to our Discord or we can continue it here.
@sdirix I just wrote a lengthy reply but somehow it disappeared on edit. So I wont type it all again.
Agree 100% on tree view. Material Design is also a keeper. There are other options than json schema. The FHIR spec has individual StructureDefinitions, ValueSets, CodeSystems, CodeMaps, SearchParameters for every resource (127 that you saw like Patient or Condition) that could alos be used to generate UI dynamically.
I cant make it compile with 3.0.0-rc.0 using the react seed project. I tried messing with the dependencies, but the whole thing kind of fell apart on me. Do you have the working code somewhere I can see it , or can you pr the seed project?
We’ll update the React seed soonish. At latest with the full release of JSON Forms 3.0.0 in the upcoming weeks.
Like I said this would be amazing if we could have a data driven forms based ui for FHIR using this tech. Everyone is going to Material UI design so we want to keep that in play. I agree on the tree editor. FHIR has 127 resources as you can see why efforts like this GitHub - healthintellect/fhir-ui: React components for displaying HL7 FHIR data using Material-UI that don’t leverage the schema cannot scale. Things get even more complicated when you get to required fields, data validation, and references from one piece of data to another. Also localization/internationalization is an issue that can only be solved with a schema driven solution. Same with new versions of the spec, and some of the unique things in fhir like resource profiling. Also, the form needs to produce valid FHIR when the user saves them. So it is imperative that we use a data driven approach.
Yes I agree, a schema driven approach certainly makes sense. Note that a potential tree editor could still be schema driven.
I just wrote a lengthy reply but somehow it disappeared on edit. So I wont type it all again.
The spam detector is sometimes a bit eager, especially for new accounts. However they are not deleted, just hidden and flagged for review. I approved your posts
