EncounterPRO-OS

The two most important concepts in the EncounterPRO-OS Clinical Groupware platform are Components and Configuration.  Think of them as dance partners.  But don't think too long; the analogy breaks down quickly.

A component can be thought of as a mini-application, or a screen, or a computer program.  A component is generally written in a computer programming language and compiled.  At the end of the day, a component is the only thing in the EncounterPRO-OS system that actually does anything.

Configuration, on the other hand, is more like the glue that holds everything together.  Configuration is stored in database tables and is never compiled (though it can be "boxed up" for importing/exporting).  The EncounterPRO platform never initiates a call to a component by itself.  It just doesn't know how.  Components are only called when they are referenced by a Config Object, and the platform is activating that Config Object.  The Component supplies the programming, and the Config Object supplies the context and fixes any optional behavior in the component.

For example, the most commonly used Component Type is a Service.  Likewise the most commonly used Config Object is also a Service.  Yeah, maybe we should have given them different names, but which one you're talking about is usually clear from the context (and it's usually the config object).  Anyway, there is a Service component for recording vital signs.  It's job is to present a screen to the user and and can put stuff on the screen like height, weight, blood pressure, whatever.  As it turns out, however, doctors take a different set of vital signs for kids than for grown-ups.  And they take different signs for sick visits than for well visits.  And for physician visits rather than nurse visits.  And for different specialties, or regions... you get the idea.  Well you don't want to write a component for each of the scenarios, not just because of the efficiencies gained by reusing the same component in all of these situations, but more importantly because the component programmer doesn't know what the next doctor is going to want on their child-new-patient-well-visit vitals screen.