I agree with a lot of @ibacher and @mogoodrich comments. In lieu of a long-winded post, I’ll just say that I’d love to discuss this more in an upcoming forum.
There is a lot to learn from what has been developed in htmlformentry around this, and the good, the bad, and the ugly from that. Clearly there is a need for us to capture observations conditionally based on either not-yet-saved encounter data, or previously saved patient / encounter data. But we should also take care to limit the amount of custom code that is embedded in forms themselves, or in placing too much undue importance on “Forms”, in favor of looking at how form components can fit into an overall clinical workflow.
It isn’t totally the same conversation, but I’d like to ensure that we are considering some of the direction that we are proposing with the encounter context in mind. The idea being that we want to support frontend components that can contribute to an encounter outside of the form engine itself but which still fit into an intuitive workflow for the user/clinician. Some examples that feature prominently at PIH are recording lab and drug orders, recording program enrollments and state transitions, and entering vaccination history.
I’d be curious to explore a model where the form engine doesn’t actually take responsibility over the entire encounter, but simply allows for “component forms” to be used to enter and render observations collected in a broader encounter context workflow.