Null orphan rows are being created in analytics table for custom SDA container. How can I prevent creation or ensure automated deletion of these rows?

Question

Question

Cyriak John · Aug 12, 2019

We have created a custom SDA container to store a certain kind of new, customized patient data.

We are observing a behavior in the correspoding analytics table for this custom SDA class where rows are added for a patient for which the MPI is null and the patient record does not exist.

From what we can tell, it seems that, when there is a MPI link/unlink, rows are added to analytics linked to the new Patient record that contains the latest MPI, but the old rows linked to the old (now non-existent) Patient are not removed. We are concerned why this is happening, since, in our testing, it does not occur with stock SDA containers (for example, the HSAA.Encounter table).

It has been suggested that perhaps there is some system code that is only able to execute to remove orphan rows that are created when a patient is linked to a new MPI when the analytics table is in the HSAA.* parent package. However, despite renaming the parent classes, we haven't been able to get data written to the custom container's analytics row in this way.

Is there anyone that has run into this issue? I would appreciate any advice on options to solve or deal with this.

Also: It appears that there is no data integrity issue with the newly created rows (i.e. the row that is populated with the patient's current MPI contains the correct information), but this issue is creating a lot of junk rows in the analytics table and makes the ingestion process look like it's functioning incorrectly. So, while perhaps running an automated process to periodically delete the rows is an option, we would like to not have to do this.

Discussion (2)0

Log in or sign up to continue

Justin Lavoie · Aug 12, 2019

I'm not familiar this specific problem. Health Insight issues involving custom SDA extensions can be tricky, and your set up might need to be reviewed by a support advisor as part of a WRC issue if no one here knows the answer. Also, since various known bugs have been fixed in recent HI versions, could you provide the full version strings of both the Health Insight and Information Exchange system you are working with? After an MPI link, an update should be sent to HI for the non-surviving AnalyticsID that has no patient data, indicating it should all be removed. You could see if these are actually being sent, and if so, why the system isn't deleting at that point.

0 0

score 0 · Answer 1 · 2019-08-13T18:59:31-04:00

Thanks for your reply. I am working with engineer Clayton Lewis on this matter. It seems that the update that takes place after the MPI link consists of an insert of a row containing a reference to a new HSAA.Patient entry, and a deletion of the row containing the old ID from HSAA.Patient (which now no longer exists). We are operating that the deletion does not occur because our version of the software requires that the analytics table be located in the HSAA root package. Incidentally, we are not able to test this hypothesis even with a custom container class object registration, because there is another error where the correctly qualified SQL table reference is not being generated.

Version string is: Cache for UNIX (Red Hat Enterprise Linux for x86-64) 2017.1.3 (Build 317_0_18225U) Mon Aug 13 2018 12:48:50 EDT [HealthShare Modules:Core:15.03.1007 + Linkage Engine:15.03.1007 + Patient Index:15.03.1007 + Clinical Viewer:15.03.1007 + Active Analytics:15.03.1007]