Software Breakout Group Notes (captured by Kevin Gomes)

One thing I wanted to highlight from the meetings is that the requirement that this must be a web app may not be entirely true. It seemed there was disagreement among everyone about apps on phones. The general feeling was that as long as the app was free to install on the phone, they did not have any issue with it. Not sure if this is important or not.

Must Haves
1. Keep track of resources (keep in sync even with instrument refurbishing) and have that reflected in planning (prevent over-scheduling the instrument)
2. Need to be able to refurbish instrument in the field
3. Authorization and workflow. Basically, there is one level of role that can defined schedules, alter schedules, etc., but that never gets committed to an instrument until it is approved by someone with the authority to do that and/or the person authoring the schedule already has authority. A slight offshoot of that is that there should be roles that can always override current scheduling. The PI/owner/organization lead should be able to assign these roles and change them whenever.
4. A ‘view-only’ mode (role) where people can see what’s going on, but not make changes
5. Push alerts. At first major events pushed to SMS, but later it would be great to be able to user define events and thresholds (think ‘when pucks get below’ or ‘when sample volume less that’) that events get sent to custom, user-managed list of participants.
6. Must work over satellite comms.
7. Data management must meet government standards. Encrypted comms, data storage security, etc. I asked if the application was run on AWS’ .gov data centers if that would suffice and they said ‘I would think so’. Something called ‘BEDRAM’ certification. I have no idea what that is or how to spell it.

Should Haves
1. Integration of other environmental data (weather, flooding events, etc.) to give context to sample data and to inform planning/scheduling
2. Should be able to group samples and define them as ‘replicates’ (would even be better to run them in parallel)
3. You should be able to leave ‘space’ in a loading of pucks to allow for opportunistic sampling. In other words, leave some spare pucks that you can burn when the need arises.
4. Some sort of ‘journal’ or ‘user entered log’ where people can record events manually to give context (think Slack channel)
5. Use should be able to set values where certain events will happen. The specific example was that I want to be notified (or instrument should stop schedule) if a certain volume is not obtained or flow rates aren’t high enough.
6. Ability to interact with sampler via hardline only (use case was on Navy base where no cell phones or wireless comms were allowed).
7. Should be able to have an audit trail of who did what on instrument (might want to check to see if there is something in the government data requirements about this particular thing).
8. We should look into existing standards and application to see if we can leverage them (see list below). I think the take away is we should make sure we are not reinventing the wheel at any level (instrument protocol, communications link or applications)
	a. DCP (data collection platforms) which already communicate over satellite
	b. FTS360 app (https://apps.apple.com/us/app/fts360-config/id1197918160) is an existing app used to interact and configure instruments.
	c. Linkcom app (https://apps.apple.com/us/app/linkcomm/id590256859) is an app used to communicate with data loggers
	d. There was also mention of SDI-12 communication protocol, but that’s pretty low level. The only thing we might want to look at is if we implemented in the SDI-12 standard, would that buy us anything?
9. There should be some functionality built in that keeps track of current state that could be re-created if the machine loses power. Another idea was you could save a ‘state’ or ‘image’ of the instrument configuration and then return it to that state by calling up a backup or pushing an image. This was mainly focused on the idea of recovery if something goes wrong and you need to wipe the controller, install a new one or something that dramatic.
10. All data should be backed up (I think the idea is that we have a local copy and that is sync’d to the cloud application and that would be good enough?)
11. There was a LOT of discussion around metadata attachment to the pucks via the RFID tag. I think the end goal is that all relevant information about the sample would be automatically written to the tag and then when the tag was scanned post-recovery, that metadata would be made available for the existing information architecture that was presented at the meeting. They use barcodes to track samples in that architecture so if a barcode could be printed from the puck id tag that would be fantastic and would make the integration into the existing system seamless.
12. Users should be able to add metadata manually that can somehow be linked to the sample and follow it through the process (maybe through the barcode).
13. Sample location should be captured on the puck ID tag if possible.
14. There should be a way to look at an individual puck/sample and immediate get the information relevant to the sample (like when was the most recent decontamination?)
15. Would be great if we could track the temperature of the samples from cradle to recovery (even during shipping).
16. Store date/time of filter recovery on puck too.
17. Would be great to have a ‘call for help/support’ button to reach tech support.
18. Should have a way to save an existing schedule as a template that could be used for future.
19. Be able to define ‘soft’ periods of time (think ‘deployments’ or ‘missions’).

Could Haves
1. Alert when a sampler is moving. We thought this should be done (at least initially) with an add-on system. If theft is a concern, add an external tracker and use an outside service to set up geo-fenced alarms.

Won’t Haves