Some questions and their answers

There are many suppliers of electronic shelf labels on the market. When we had to make our decision, we chose Pricer because it is the only supplier that works with infrared data transmission.  We did not dare to support a product for which there are no validated studies on human and animal exposure to active electromagnetic radiation. With infrared light we can

a) eliminate this risk and

b) be sure that only cages of the room in which the transceiver is attached are detected.

a) In laboratory animal management, special requirements play a decisive role. Since important decisions are made and documented on site in the animal room on the basis of cage cards, we had to ensure that it is always traceable which cage card display was at which time at which cage or is now at which cage. It is also more comfortable for the animal welfare officer to view the cage cards in a sorted order than to have to put complex queries on the database. Audit reports and billing records had to be generated in an animal facility specific manner. Last but not least we had to provide a tool, which makes it easy for Animal Management Software provides to integrate the CageTalkers® system.

b) In contrast to price tags on shelves in shops, cage cards on cages in experimental animal facilities are handled much more dynamically. Any change in cage contents must result in an update of the cage card. Be it in breeding, in experiments or in stock. The cage contents and the status of the animals and cages must be constantly documented and reported. If animal husbandry is to be managed sustainably and made comprehensible from a 3R perspective, additional services such as the forwarding of “alerts” are also required. All these requirements could only be met with a special application.

c) In fact, we do not know which Electronic Shelf Label (ESL) solutions will become widely accepted for which markets. There are many different aspects to consider. Do we need cage tracking indoors or outdoors? What role does the localization of cages play. How are the animal rooms equipped with communication technology? How can solutions be easily maintained. How is the troubleshooting. How can standard connections to existing solutions be realized? How flexibly can changes to the labels be implemented? What happens with the historization? We have therefore developed our own middleware for the CageTalkers® services, so that theoretically we could also integrate other label systems that support SOAP or REST. However, for animal husbandry we are 100% convinced of the infrared technology. Since we work with our own medium, we can exclude external disturbances, which makes maintenance much easier

We believe that documentation should be as simultaneous as possible to the physical animal transactions. In fact, we have not only given a lot of thought to this but have also developed solutions. For example, to achieve this simultaneous documentation we have developed a mobile, battery-operated worktable with monitor holders and integrated RFID readers for reading RFID-marked cage card holders and an integrated printer. In the end we had the problem that the printers and paper cutters in a clean room could not be operated reliably enough and the service in clean rooms showed to be complicated. Out of the necessity to solve this, the electronic cage card, which combines display, identification, signaling and a central control e.g. from the IT department, was born as the first step. In the continuation of this development, the web services and an application were created to combine colored buttons with a mobile app or the AMS and to communicate these “alerts” to the outside world. Now the notified user entering the animal room later, can see all cages, on which cages work must be done by seeing the LED flashes and the buttons.

Basically CageTalkers® work with all AMS that integrate our standard Web Service. These messages can be structured very deeply down to the animal level with their services and medical records or only on cage level. We have tried to make the integration as easy as possible and left the AMS supplier the greatest possible freedom in the interface. This are SOAP messages that send the cage card data in an XML string. We render this string and convert the data into images. We also support our AMS partners and customers with sample XML files and layouts to be loaded and tested with the ClientApp.

No, we do not change anything. We take the data from the web service into our database and generate the CageTalkers® images based on the templates agreed upon with our customers.

What we receive from the AMS is not touched. Only if the AlertButtons are used together with the AlertButtonApp. Buttons can basically be used with and without the AlertButtonApp or with the mere web services. If the AMS uses the AlertButton web services absolutely nothing is added. If you want to send the alerts automatically, first scan the CageTalker and then enter the buttons by confirming the button in the Alert selection or by scanning the NFC ID of the button.

This question only applies if the label server is hosted in the cloud. Our customer must then provide us with an IP address to which we can for example send the data via port 950. The data, in this case images, are then forwarded to the fixed IP of the base station via so-called forwarding rules on the firewall for certain ports and defined IP addresses. As there are no possibilities to branch off from this port which directly leads into the base station, this is a secure solution. If a customer still has a problem with this, we can alternatively attach the base station to a G4_Router with a SIM card and send the data independently of the customer’s network. The prerequisite is a reasonable mobile connection.

Cages with CageTalkers are tracked automatically by so called audit jobs. The intervals for this audit job can be configured by the user in our web service administration. The audit data (Job plus found cages with time and location) are stored in the Warehouse/Cards-Database.

Apart from this the Pricer Server sends so called broadcasts to all labels in the facility on certain intervals. The CageTalkers answer to the nearest transceiver, normally one in an animal room. This is how the locations/rooms of the cages are found automatically. Also, the intervals for these broadcast parameters can be defined.

Yes

This the customer decides. Normally we only do the pilots as a hosted service, because of saving installation cost. In this case only the infrastructure (Basestation, Transceivers, Labels) are on premise at the customer and all Software is running in the cloud in our data center. We only send the images on port 950 to firewall of the customer and the firewall forwards it to the fixed IP address of the base station at the customers.

However, for productive operation the infrastructure and the software are all hosted on premise at the customer and the communication happens in the Intranet of the customer only.

In general, independently where the software is hosted,  our web services receive data from the AMS, triggered by the AMS, when the AMS creates a cage card based on a changed cage content or when flashes are requested. The AMS can get feedback from our web service by the return messages for all transactions it triggered. Additionally there are web service methods like, get  status of the label, get  roaming status, get locations, get  inventory and get billing records. It depends of the AMS provider, how deeply these standard methods are integrated.

In some cases, it would really make sense that our web service actively posts data to a web service offered by the AMS offers not triggered by the AMS.

We currently know 2 situations where it would make sense for the AMS to actively offer web services:

a) To update the topical location automatically. E.g. The user moves a cage from one room to another but does not update the AMS with the new location actively. As I told the Pricer Server sends broadcasts to get status and location from a cage label on certain intervals. The location could be automatically updated in the AMS if the AMS offers such a web service.

b) To save alerts, which we record on the base of our buttons in the Warehouse/Cards-database. We are offering colored buttons which signal certain cage states in the animal room manually. With the App a user can message e.g. “Animal found dead “, “Animal sick”, etc. to a receiver (e.g. Animal Welfare officer or Scientist) outside the animal room.  When the user, e.g. Animal Welfare officer later enters the animal room, to take care about the cage and animals he was notified, all cages where some work must be done can be flashed. This App uses web services of the Warehouse/Cards-Database but not automatically forwards these alerts to the AMS. To get those alerts also the AMS must offer a web service.

From the Warehouse/Cards database we currently offer standard audit reports (inventory and location) and billing records reports. The reporting possibilities are continuously growing based on customer requests. Of course, the Warehouse database can be additionally queried with any SQL or any reporting tool on the base of a much simpler structure of the Warehouse/Cards-Database compared to the AMS database, as AMS databases are also optimzed for processes and not only storing the data.

An other reaso, why we call the CageTalker also a common denominator is that by e.g. moving a cage through different rooms e.g. Animal holding roomsProcedure roomsStorerooms for samples and scanning each time scanning the CageTalker LabeID in another system the data can be collected in one warehouse database and still update the same label. With the first update of the label a systemID is created which keeps the data linked, when the label is reused. This gives completely new possibilities for quality assurance and for reporting.

Of course, it is technically also possible to query the AMS database.

Also consider that the CageTalkers database contains data from really produced Cage Cards with a date and a timestamp and a history for each cage. The AMS might only stores the data without the information when the cage card was created and how it physically looked like at the very moment when it was produced.

The basic principal is on each change of the cage content a new cage card must be printed.

In an idela case using CageTalkers the user would scan the cage label to quickly find the cage in the AMS, then sacrifices the animal in the AMS, and the label is automatically updated at the cage. Everything working in between like the web services is not visible to the user.

Our service updates in a few seconds. In what time the AMS syncs the new cage data by sending us the new data is a question for the AMS provider.

Additionally, we have a ClientApp which allows to have a look at the Cage Labels from wherever you are, independently of the AMS.

The data can be sent on an individual animal base with all data like animal base data like strain, age, gender,etc, services and medical records, litters, pups, genotypes, etc. per animal.  In this case we internaly do the aggregation for the cage card if needed, but have the data on an individual animal base in the database for e.g. reporting. Some systems only want to send us aggregated data.

The  question here as well is that some AMS systems are configured in a way, that they only administrate batches of animals but not cages. Of course, a CageTalker identifies cages and can show the batch on its display, but it not marks the batch individually. It marks a cage. You should clarify this question with your AMS provider from the very beginning. I you want to use a batch-oriented system speak with us and we can show you how to distribute the batches to cages.

We prefer to get individual animal data compared to only getting cage data because there are better possibilities for:

a) Better reporting possibilities on the base of individual animals

b) We can add quality assurance criteria like e.g. only animals with the same strains in one cage, animals only animals with the same protocol in one cage, etc. We evaluate the data with the integrated expert system and can inform the user e.g. about logically wrong data in one cage on the card or by a message.  In such a case the data in the AMS can be corrected.

Currently we support SOAP because it is very formalized and nicely readable for a 3rd person. We are planning to support REST any way.   But have not yet started with the development yet. If this gets a high priority, we will speed up this process. However, all our connected AMSs support SOAP. I would estimate a development time of about 4-5 weeks to support REST.

Our first customer was in the USA, which currently runs 14.000 labels in as far as I know over 50 animal and procedure rooms. The integration was done by another developer for his proprietary system, we sold the CageTalkers.

A Pharma company had 1.600 CageTalkers in the last 3 years and now ordered another 5.400 for about 40 rooms. And there are others.

Yes. The  Pharma company is using  3 pages for the breeding and 3 pages for clinical. They also use the dynamic QR-Code to redirect to other web pages. How you would distribute the data to 3 pages is up to the Client and his philosophy.

I personally would put data for the daily operation on the first page to facilitate simultaneous data capture and historical data which I do not need so often on the next pages.