Summary statistics in HospiNet object are actually computed from the original base

[ClementMassonnaud]

Some of the statistics in HospiNet object are actually computed from the original base. They are computed from the base with the functions all_admissions_summary() and per_facility_summary() and then passed to the object.

For me, this is an issue. For instance, if accessing the number of facilities with net$numFacilities we actually get the number of facilities in the original base, not in the constructed network, which is what I would expect (actually this is computed by net$n_facilities). The same applies for the rest of the summary statistics

I would suggest to make a clear distinction between the statistics computed from the network and from the database. I think that only the statistics related to the network should be in the HospiNet object. The statistics related to the database can be computed using the functions externally.

[PascalCrepey]

Hopefully, there will be not much differences, but I agree.

[tjibbed]

I can see what you mean... Some of these statistics are not part of the network, but rather of the database itself, and I agree that we should treat them separately.

However, I would want to argue that quite a number of the statistics calculated by per_facility_summary() are actually part of the hospital network. I think that the possibility of including these makes the HospiNet object stand apart from a "standard" igraph.

For instance, the number of admissions per facility gives information about what proportion of these are transfers / movements. Whereas mean length of stay gives a measure of size or patient volume of a given facility. To me, these are facility-based stats are an important part of the hospital network.

I will have a look and see if I can separate the stats that are part of the network from those that are part of the database, and move those belonging to the database to the checkBase report

[PascalCrepey]

Well, I think the potential problem is when there are discrepancies between what's in the base and what ends up in the network. For example, because we modify the number of admissions to deal with overlaps, the number of admissions per hospital in the network will not be the same as the one in the base. I think it's ok to leave everything in the HospiNet object, but maybe we need to differentiate them...

[tjibbed]

I've created a bit of a stricter separation between what are network properties (belonging in the HospiNet object) and what are summary stats about the database (returned by checkBase())

This way, the workflow allows the user to check the database and get a quality report with stats on the database and errors therein. After that, the hospinet object can be created, and all information on the specific nodes (i.e. facilities/hospitals) is stored there.

Does that resolve your issue, @ClementMassonnaud ?

[PascalCrepey]

@ClementMassonnaud, @tjibbed, can I close this issue ?

[tjibbed]

Yes, I agree.