Adding proprietary extensions to questions

[fatso83]

Is your feature request related to a problem? Please describe. We would like to say that "when processing this question item, look up the threshold values for this patient's bodyweight". This is thus not a presentation/rendering issue, but related to adding additional meta-data about the question to be used by a processor when processing the submitted QuestionnaireResponse.

The most straight-forward way we could see how this would be implemented would be by adding an extension

{
   "url": "https://our.proprietary/fhir/StructureDefinition/extension-validate-using-threshold-value",
   "valueCoding": {
              "system": "https://our.proprietary/fhir/ValueSet/threshold-values",
              "code": "bodyweight"
    }
}

Describe the solution you'd like An optional "Additional extensions" box. Either a dumb "JSON blob" type of input field or some kind of smarter form to help fill in the possible variations (not something we need).

Describe alternatives you've considered Was wondering about making our own "questionnaire enricher" import module that would take a Structor exported questionnaire definition and make it possible to add some blob of JSON extensions to each questionnaire item.

Additional context Add any other context or screenshots about the feature request here.

[KimHoelHalvorsen]

The only way to do this today is by adding it to the json document. We will not add such an option any time soon, and adding raw json-code in a UI for non-programmers is not the purpose for this tool.

[fatso83]

That is of course totally fair and I would not suggest you add it either! Bloat scope is murder to any product 🔪 For now, I guess we will just keep on manually editing/enriching the produced JSON schema and ponder creating a user-friendly UI for it. Still ...

It is quite obvious that organizations using Structor at some point will have needs for custom functionality not covered by the Structor tool and having some general guide lines to deal with this problem in a fashion that is in line with your thinking would be beneficial. I was just wondering about what you had in mind when designing this.

I think no one is interested in maintaining forks of Structor with custom functionality, but there are alternatives to avoid scope creep in the core: support extending the product through an API. Has this been discussed? In pseudo-code something a la structor.init({plugins: [myCustomPlugin, myOtherCustomPlugin]}) where these plugins could receive for instance receive some references and return components that should render to specific parts of the application.

Something like

const myPlugin = structor.createPlugin( React => {
    return {
        transform(schema) { return schemaWithCustomExtensions(schema); }, //  enriches the FHIR Questionnaire schema
        HeaderNode(props) { return <div>... </div>; }, // rendered to specified place in the header
        FooterNode(props) { ... return <div>{props.schema.title}</div>; } // rendered to specific place in the footer
    }
});

// props could include stuff such as `updateSchema(schema)` that could be used to capture additonal user data

Would something like this be interesting to have? This might be a good candidate for externals to create a PR for, but the concept would of course need a chance to be accepted before investing time in trying to squeeze it in.

[kennethmyhra]

Thanks, can you create a new issue with this proposed solution so we at least have it logged in a directly related issue. If you got the time to implement it, give us a PR and it isn't too intrusive we can consider to add the plugin solution as a feature