“Can we have the data?” sounds like a clear request until I try to decide what to build. Which records, for what period, at what level of detail, and for what purpose? In hospital data engineering, clarifying those questions is part of the work behind the data.
Find the question underneath
I begin by asking what someone needs to understand or do with the output. A request for a daily view may be about spotting changes over time; a request for record-level detail may have a different purpose and carry different considerations. The answer shapes the data product more than the first proposed table does.
It also helps to agree on the unit of analysis early. Are we discussing people, encounters, appointments or another event? Naming that choice before development reduces the chance that a technically correct dataset answers a different question from the one the requester had in mind.
Make the boundaries explicit
More detail is not automatically more useful. The intended purpose, the audience and the handling requirements all matter when deciding what fields belong in an output. I treat access and information governance as part of the design conversation, rather than a final check after the data has been assembled.
That conversation can include the period covered, the necessary level of detail, who will use the result and how it will be accessed. These are practical questions, not obstacles to getting work done. They help keep an output proportionate to its purpose and easier to explain.
Agree what done means
Before building, I want a shared picture of what a useful result looks like. That might include a definition for each key measure, an example of the expected shape, or a note about known gaps and timing. A small amount of agreement up front gives everyone something concrete to review.
A good data request is not just a list of fields; it is a question with enough context to answer responsibly. If the purpose is still unclear, the best next step is usually another conversation, not another query. That is one of the quieter but essential parts of data engineering in a hospital.