Currently I'm working on implementing HL7 CDA for a large hospital which has both outpatient and inpatient clinics. To decrease average duration of consultation, consulting physicians use electronic forms. Forms must be thoroughly formalized (and ideally require minimum keyboard input).
In practice it appears that simplest formalized Consultation Note form contains not less than 40-50 input fields.
For example, an ordinary otolaryngologist's Consultation Note "Physical Examination" section includes the following sub-sections: external nose, internal nose, throat, larynx, trachea; note that nose is symmetric, and that each organ can be described by 10-15 characteristics - so as a result I have an input form with about 100 input fields. Add to this form other required sections defined by the HL7 CDA Consultation Note spec (reason for visit, history of illness, problems, medications) - and you have got ~150 fields. Consequently, my HL7 CDA level 3 document body shall contain the same number of [observation] elements.
During an ordinary in-patient case physicians can register up to 10-100 documents. And each document contains 20-100-200 meaningful parameters. In total: ~10000 parameters.
At the end of the in-patient case a physician shall create a summary document which gathers data from other documents registered earlier. And at this point I feel that I misunderstand HL7 CDA spec. A human being cannot operate with 10000 parameters easily. Could you please give me an advise (or example) on how to design ergonomic user form that allows a physician to create a brief Summary Document?
You're not misunderstanding the basic premise, but on the issue of providing a "human-readable display, don't try to associate independent display values for each tiny observation.
CDA allows you to provide <text> nodes as part of each segment, which are generally HTML data that will be displayed when read by a human being. For encounters with lots of observations, retain the parsed observations in the CDA, but each individual observation value should have a null <text> value (one that doesn't display to the provider). Instead, provide an HTML/readable version of all the observations in a higher-level parent node (so you'd have all of the observations about the "Nose" in a single HTML table stored inside the <text> node of the segment titled "<title>Nose</title>". Or - even better - you could even go to an even higher-level segment than this, and store a full HTML version of the entire observation section of the SOAP note along with the general practitioner's notes in the <text> node associated with the encounter <section>.
Long story short: formally retain all the values in the CDA, but consolidate all of these observations into a single human-readable display (HTML) in the <text> node of a higher level node. This will allow a nice-looking display for the provider, but retain all of the codified data for machines.
Have a look at Blue Button Plus for some CDA examples that might make the whole issue a little clearer.