For implementation I’m of the opinion that we should own everything besides printing the labels. There is only the one path of data between the consumer and our server+database in a cloud center. We nor the manufacturers should be able to advertise to consumers through this, and consumers should be able to understand the barcode no matter what chain got it to them. We have to build consumer trust for these barcodes to matter.
I live in the USA, but the report centers around Kenya. If we’re not talking about one government then handling regulation is a key and large part of this project. If we’re working in more than one country we’ll need to have language translation done. I still think we need a connected partner organization that's done such things before. Even the manufacturers and distributors may have a limited connection to our servers. What kind of operating systems are these people using to print labels? We can’t be a manufacturing bottleneck, so perhaps we’d need to provide blocks of barcodes instead of individually requested ones. Perhaps a worker goes somewhere else and walks in a drive with the barcodes. That barcode library seems not done - we’ll probably need to support our own. I assume this will be open source and those using the system will want to review the code. Here’s my take on the process: 1. Manufacturer asks us for a barcode block targeting a distributor for a product 2. We generate that number of PNG barcodes containing individual UUIDs that in our database is matched to a product ID, manufacturer ID, and distributor ID 3. Manufacturer downloads the block and applies the images to their label printing process 4. Distributor scans a subset of these barcodes and for each sends us a verification request with the scanned UUID and the three IDs independently provided 5. We mark each as distributor scanned in our database, and now we know a block has at least some scanned, or we indicate to the distributor that there’s a problem 6. Distributor distributes product with original manufacturer’s barcode intact, scanned or not 7. Consumer uses our app to scan the barcode, and we then tell them if the distributor verified part of the block, if it has been previously scanned by a consumer, who the distributor is, what the expected product is, and who made it, all of which can be compared to the label. Matt On Tuesday, December 26, 2017 at 9:00:17 AM UTC-6, Frank Davidson wrote: > > Yes, that's the Aztec library I saw for creating the codes. Looking now > for a good OS library for reading them... > > I'm thinking the sequence would go something like this: > > > 1. Manufacturer creates key pair > 2. They register their public key with our central server > 3. The public key is posted on a URL REST endpoint on their certified > domain > 4. They download our code/library which enables them to create unique > Aztec codes at manufacturing speed signed with their public key > 5. The Aztec code payload would be JSON containing the above mentioned > URL, by default a UUID, and any other metadata they would have the space > to > include. The payload would be signed with their ECDSA signature. > 6. That unique Aztec code gets, ideally, printed on an individual > bottle but could also maybe be code for a shipment or pallet or some other > grouping if individual bottles are cost prohibitive for some manufacturers > 7. An individual or small pharmacy upon receipt of the drugs would > scan the Aztec code in our "App" or website > 8. If the signature checks out they are forwarded to the URL in the > JSON payload > 9. The cert of the domain is verified > 10. The rest of the JSON payload is relayed to the manufacturer. > 11. The manufacturer can then track the individual bottle and/or offer > other info/services to the individual user. > > Thoughts, comments, and criticisms welcome! > > Frank > > > On Monday, December 25, 2017 at 4:46:49 PM UTC-5, Tamás Gulácsi wrote: >> >> https://github.com/boombuler/barcode is a MIT licensed Aztec code >> generator. >> >> You'll have to become a trusted central authority for the drug companies >> - or at least provide the infrastructure for the government to force such a >> central registry for uuids and public keys. >> >> I think here the technical solution is almost ready, you have to assemble >> already existing components. The bigger problem is to build the concept and >> make a lot of important people accept it. >> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
