Take care of a big caveat please: all health information systems start and
end with the human being. We should use the IT support that Thomas suggests
where possible, but.... to the extend that humans cannot make mistakes. And
the governance of archetypes / DCMs / valuesets / etc does require human
intervention and hence human understanding. So naming conventions are
important and are a different beast than the versioning of the file /
content.
Thomas' trick with the software reading the meta information is fine for one
specific purpose eg a record handling 100 archetypes or a composition of 88
DCMs. However, what if that same system must do this for all 100 archetypes
for 25 - 100 diseases per specialty, with 30 specialties (100 x 25 x 30) and
allowing all kinds of combinations so x n. Beside the safety and quality
also performance comes into the picture. And I am not speaking yet of each
use of these combinations, e.g. for screens / data entry, storage,
communication, querying, aggregation, decision support etc.
“Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil”
Knuth, Donald E. “Structured Programming with go to Statements.” ACM Computing Surveys (CSUR) 6.4 (1974): 261-301.
In 1974, when memory and processing power was very expensive, programmers were busy doing a lot of poking and peeking and jumping to save memory and processor-time, and causing bugs because there was no safety protecting them against errors.
We have cars with the power of 300 horses or more. Do you need to understand horses to drive them?
There is nothing you can learn from programmers from 1974.
the 'trick' I mentioned is for design / modelling environments where source artefacts are in use. Production environments use only pre-compiled templates, represented in an optimised form for the relevant environment; there is no need to worry about parsing source files. A typical production environment might have some hundreds or thousands of screens, and additionally some dozens of messages, documents or web service interfaces to specific data sets (a la FHIR/SMART). Deploying these number of compiled artefacts (or even 10x these numbers) is easy to do.
