When designing a novel system in a hospital or other clinical setting, I think it would be important to gather information from doctors, nurses, pharmacists, technicians, et al on use cases for the system.
Aside from the fact that all of these are also busy professionals, what is a good way to get them to share information pertinent to their (possibly chaotic and time sensitive) workflow that would be usable in a software engineering design?
The only way to reverse-engineer what medical professionals are doing is to observe first hand, while they are working. Find and follow willing, chatty professionals like white on rice, and ask them to narrate the work and thought process. If they need prodding, ask questions that drive towards rules, like: What are you thinking? Why did you choose this over that? What are you looking for? What does that rule out?
As you learn, share your mental model, and ask questions that shape & refine the rules. Be the journal of their work.
Anything short of active, hands-on, in-person, respectful observation and feedback is guessing .. not engineering.
Another openEHR-related answer, from a slightly different perspective...
The openEHR approach has been having considerable success in standardising clinical data requirements - ie clinician-defined EHR content specifications; clinicians and stakeholder expert collaboration to ensure the models are valid, safe and correct; and governing/distributing them for use in clinical EHR systems. This standardised approach certainly helps to simplify capturing the workflow process, including documentation of orders and corresponding activities, thus enabling the tracking of workflow. The openEHR Clinical Knowledge Manager is acting as the hub for this activity - www.openEHR.org/Knowledge.
Some jurisdictions are starting to use this approach as well for creation of national eHealth standards - http://www.nehta.gov.au/connecting-australia/terminology-and-information/detailed-clinical-models and http://dcm.nehta.org.au/ckm/
Some professional clinical colleges are also starting to think along these lines too, to ensure that the software being built by vendors is safe and fit for clinical use - I'm aware of early activity happening in Australia, UK and US.
Invest in domain specific languages. From a software development point of view, clinical software is tricky, because you can develop software in the right way, but you'll have a hard time developing the right software. Even the brightest business analyst or software developer has a hard time communicating with clinicians.
In health IT domain specific languages (mostly) correspond to electronic healthcare record related standards. Check out http://www.openehr.org If the clinicians can express their requirements using a computable language that describes the domain, you'll find it much easier to turn their requirements into software. To see an example of the approach I'm talking about, you can take a look at our open source project: http://opereffa.chime.ucl.ac.uk
Jumping off of David's post: Are you looking to develop a general EHR product or do you have a specific client site installation? We are developing an in-house Oncology EHR system and I don't even know where this project would be without being in the office everyday. If you really want to learn a practice, you really need lots of face-time and time where they point on your screen the way it should be different.
The further away from your customers you are, the slower the communication and the more you are programming to what you think they want, and not what they want.
And remember: most features will affect multiple people, nurses, admins, etc. so it is key to have input from everyone and make informed decisions.
