Add Flexible Data Fields in infinity POC for Additional Customer Data
No description provided
Guest
Oct 30, 2025
If I may, since it is just storage, simply redefining the schema of the relevant tables to permit more field length is something the upgrader script could perform for an upgrade to a future navify POC Operations version. Yes, IRIS would have to chew on it a fair bit to restructure the table, so it would definitely be some processing time added to an upgrade, but we have seen the tables modified many times before, so this is not unusual. Simply lengthening the Description, Role, and other textual fields would not have to wait for the new Operator Management module, perhaps.
Current field lengths are far too small (30 characters for some, 50 characters for others) for the additional fields added in navify POC Operations. 256 or 512 would be more useful, especially for sites that heavily describe their operators, their circumstances, whether they are travelers, contract dates, and so on. This comes up when migrating operators over from a competing middleware system, and they have this extensive documentation that the customer wants brought into our system. These are just text fields, not something needing processing, merely storage. However their absence, or in the current case in 2025 them being too short, it is a competitive failure and is noticed by customers.
The flexible data fields are needed on the Patient and Visit database tables
Roche engineers need the ability to name the data field (Field Label), and the customized field label needs to be displayed in our infinity POC solution
Roche engineers also need to be able to configure which of the flex fields are visible in infinity POC and which will be hidden (Data use only)
Nice to have functionality: Allow filtering and sorting by these flex data fields when they are configured to be visible in cobas infinity POC solution
If I may, since it is just storage, simply redefining the schema of the relevant tables to permit more field length is something the upgrader script could perform for an upgrade to a future navify POC Operations version. Yes, IRIS would have to chew on it a fair bit to restructure the table, so it would definitely be some processing time added to an upgrade, but we have seen the tables modified many times before, so this is not unusual. Simply lengthening the Description, Role, and other textual fields would not have to wait for the new Operator Management module, perhaps.
Current field lengths are far too small (30 characters for some, 50 characters for others) for the additional fields added in navify POC Operations. 256 or 512 would be more useful, especially for sites that heavily describe their operators, their circumstances, whether they are travelers, contract dates, and so on. This comes up when migrating operators over from a competing middleware system, and they have this extensive documentation that the customer wants brought into our system. These are just text fields, not something needing processing, merely storage. However their absence, or in the current case in 2025 them being too short, it is a competitive failure and is noticed by customers.
Planned as fundamental building block of next generation modules
The flexible data fields are needed on the Patient and Visit database tables
Roche engineers need the ability to name the data field (Field Label), and the customized field label needs to be displayed in our infinity POC solution
Roche engineers also need to be able to configure which of the flex fields are visible in infinity POC and which will be hidden (Data use only)
Nice to have functionality: Allow filtering and sorting by these flex data fields when they are configured to be visible in cobas infinity POC solution