Data Flow Diagram for patient information system for a hospital
https://softwareengineering.stackexchange.com/questions/408198
-
09-03-2021 - |
문제
I have an example for a DFD for a patient information system implemented in a certain hospital. The below figure, represents the overview diagram (level 0-diagram, if we consider that the first level is the context diagram then the second level is level 0 diagram and so on):
In this system, patients can search and make appointments. I try to understand the data flow that is labeled patient name
and that is directed from the process Make appointment
to the database Patients
(see yellow hightligh in the diagram).
I don't understand why we have this flow in our system: In which scenario would the process Make appointment
send to the database patients
the patient name ? Shouldn't the patient name already be sent by the process maintain patient info?
해결책
You seem to be mislead by the name of the process Maintain patient info
, which suggests that patient records are created there.
If we forget about the assumption and look at the flows involving the Patients
data store, we can see:
Patient Info
flows out toMake Appointement
andPrepare Reports
Patient Info
flows in fromMaintain Patient Info
. But the flow is in labeledUpdate to ...
. This is more restrictive than just an inflow of patient data: it supposes that the data already exists.Patient name
flows in fromMake appointment
.
Using DFD semantics and assuming the DFD was drawn respecting the rules, we can understand that:
- When a patient makes an appointment, the patient name may be stored in the data store. This means that new patients are only created when appointments are made, and they are created without any other info.
- Patient info is managed with maintenance process (but not when making an appointment).
- New patients are uniquely identified by their name.
- Probably
patient name
is a part ofpatient info
(since it is never extracted explicitly).
Remarks:
- A DFD data store is "passive": data that flows in is stored, and data may be extracted from the store. Any other reaction to an inflow than storing, requires a process. So this name flow shall in now way be misunderstood as a query.
- Patient name would not be sufficient in the real world to reliably identify patients in view of potential homonyms.
- It is also strange that
Perform billing
does not needpatient info
.