I’m trying to get a single value column to populate from a choice component, which I’ve done multiple times in the past, and it isn’t working. No issues with the naming convention - I copied and pasted from the original column so all characters / spacing are the same. I’ve deleted and rebuilt the columns a few times now just to see if there’s a glitch in the matrix but no dice. I’ve even refreshed my browser.
The Choice column values are from the Colors column (two over). The single value column looks like this:
I feel like I’m missing something in plain sight… please help!
Well, it would be a lot easier if you only worked with a single row and that choice component would populate one row. Might help to understand why you are updating a value on the third row instead.
Yes, you could use a Lookup column to get an array of all values in that entire column and then use the single value column to pull out the only the first item from that lookup array…but, I think you would back yourself into a corner if you have a value in the third row, and a user actually updated a value in the fifth row. Then your single value would end up returning the wrong value.
Based on what I’m seeing in your screenshots, something doesn’t look like it’s set up correctly.
I’m trying to replicate @Robert_Petitto 's dynamic filtering technique using single value + ITE columns based on a static element (medication) and a dynamic element (patient weight). In order to get the information to display correctly, I had to make each row a specific treatment protocol. They are presented in three (3) individual tabs with specific filtering so that when the protocol is chosen on the prior screen, it’s displayed independently in each tab.
So, the roundabout answer to your question is: the value won’t begin until the third row because that’s the first row where the value would apply. The user could, potentially, populate a value on any row between 3 and 30. You’re saying that I could use a Lookup then pull the value from there using single value?
Normally, when we used single value to create dynamic filtering, it’s either coming from a column in the same table, but the user only interacts with the FIRST row only…or we use a completely separate single row table for the tab, with takes the user inputs, and then the other tables pull in the single value for you to set up your filters.
Yes, you could get around it with a lookup column, but are you saying that there would never ever be a situation where a user could end up populating a value for that column in multiple rows? It just feels way to vulnerable to me. Instead, I would either force each tab to connect to the first row only, so that is the only one that’s touched by the user, or I would create separate single row tables for each tab. Then the user could enter their criteria, and you would know exactly where to pull that value from. Right now you are giving it a moving target as that value could be in any row.
Like I said, it just doesn’t feel right. I think it may be over-complicated as it is now. If you can share a video of your app flow, or possibly a copyable link to your app, it might help for me to understand how you have things set up right now, and I can suggest a better way to do it.
The copy of your app is not copyable. Maybe you didn’t intent for it to be, and that’s fine, but it would help if I could make a copy of it and dig into it to see how everything is set up. At the very least, could you point me to the section of the app that is giving you trouble?
Sorry about that - like I said, totally ignorant here. I’ve checked that box in the app.
The issue that I’m having is with the two GTs: PEDS Patient Management and PEDS Calc Chart. What I need to do is dynamically fill in the list components with information from the Calc Chart based on the user’s choice in the choice component.
Since I’m viewing the app as a fresh user, the tab is locked down and I can’t select anything in the choices, because the value in the entire ‘PEDS Policy Choice’ column is empty. It you wipe out that column through the data editor, you will experience the same issue.
The above issue is due to the fact that several of your tabs have a Policy Choice filter at the tab level to check if the choice is not empty. This is why your selected choice is writing to other rows instead of the first row. The tab is attaching to the first row that does not have an empty choice value. If you have no filter, then it will attach to the first row in the table.
So I have a couple of follow up questions. How does that Policy Choice value filled in each table? And, why are you filtering the entire tab? I mean, I think I might partially understand what you are trying to do, but I’m still trying to wrap my head around it.
The tabs are filtered by patient type (ALS, BLS and pediatric) to help the field provider determine the appropriate, but more importantly - correct - treatment modality by acuity level and / or age. On the protocol selection screen (the one prior to the three tabs appearing), the choice that the user makes when viewing the specific protocol then writes the policy number to all three (now 4) tabs in the POLICY CHOICE column and the filter then only shows what is in the row where the number is written. The user can then navigate between the three tabs and see the correct information and when they hit the floating back button, it uses a custom action to clear those previously written values and return to the selection screen. It is by no means sexy but it works.
Apologies - I’m a little too close to this app so I’m doing a poor job of explaining it.
The REMSA Treatment Protocols tab is the current, live iteration of the app that the end users see. I created the TEST TEST TEST tab to work on these changes then conditionally hid it so that when everything is done, I can unhide it and delete the other one without anyone knowing what was going on behind the scenes.
Sorry, it took longer than I planned. Ran into a few issues…
Alright, I didn’t want to veer too far from how you had everything set up. I think I probably would have done some things differently, but you have a pretty good structure as is, so I tried to stick with what you have…but…I did make some changes that I think will help you out in the long run, so I ended up doing a few things.
First of all, I changed your protocols/policies screen to use a single inline list with grouping turned on by category. You had several inline lists and each one had a custom action, which seemed like a lot of work to maintain. Now it’s a single list with grouping and a single custom action.
Next I created a new Patient Management Selections table. This is a single row table that will hold the selected policy. Instead of setting your policy in three tables, you only set it in one and then pull it into each of the three tables using a single value column.
When you select a policy, now I just directly write to the new table instead of writing to the three separate tables.
There was an issue with your back buttons never clearing the policy choice in your PED table. You had the set column action, but not the ‘Clear’. This could have bitten you if it was not caught. I replaced it anyway to clear the selected policy in the new Selections table.
Any column that I marked for you to DELETE, I had used the Find All Uses function to find any that used that column and replaced it accordingly.
So I ended up changing a bunch of stuff that you weren’t asking about (Policy Selection). The plan was to do something very similar with the LBRT choice that I did for Policy Selection, but unfortunately I failed to remember that you can’t set a choice through a single relation without calling an action, such a clicking a button. So instead I went back to a varied version of what we originally discussed.
In the Selections table, I added a relation to link the selected policy to the respective policy in the PED table, then added a lookup column to pull in the selected LBRT choice into the Selections table.
Then I added a lookup in the PED table to pull the LBRT back from the Selections table, but onto every row, like you originally wanted. I’m not sure what you wanted to do once the LBRT was on every row, so I left it at that. Technically you could avoid the Selections table and do something similar purely in the PED table.
I’m still not crazy about how all of this is set up, but I think with all of the changes I made for selecting a policy, it will be much safer. One thing that bothers me is how you are hiding the Policy Manual tab with CSS. I still think this could be trouble, but not as bad as before. For example, I can click on the Notification tab, which does not have the CSS, and it allows me to get back to the Policy Manual tab. With your old setup, it was absolutely possible that a person could have selected a policy, made it back to the Policy Manual tab, and selected another policy. That would have allowed two policies to be selected in each of the three tables, but only the first one would have ever shown. This would have been a mess. With my changes, they can still do the same, but now when they select a different policy, it will overwrite the policy in the Selections table. The worst that can happen is that they can bypass the floating back button, and the LBRT choice won’t clear, but I think that’s less of an issue.
OK, I think I covered everything that I touched or had concerns about. You have a lot of actions and relations going back and forth, so it becomes confusing to explain. The Selections table is new. Any columns I feel can be deleted are marked as DELETED. Any columns I added are marked as NEW. I reduced your Policy Selection to one single inline list with grouping, so there is only one custom action to deal with as well. I would also check any other actions that you had set up for the Copy and Clear Policy, since I made some changes. The end goal of getting the LBRT choice on every row was achieved.
As a side note, instead of a single value of a single column, I used a Single Value of a Whole Row, which acts like a single relation. Then I used Lookups against that single value row. I could have used Single Value (single columns) to the Selections table instead, but it’s all preference I guess, and I still need the Single Value (Whole Row) to set column values through the single value row. I tried to make it as easy to understand as possible.
I expect questions, but I hope it’s understandable for you to reproduce.
Jeff - this is amazing and more than I had hoped for in terms of assistance. You are an officer, a gentleman, a mensch and, clearly, your apartment smells of rich mahogany and you have many leather bound books . Your Glide expertise is on full display here.
I see exactly what you did and in trying to recreate it, I have one last question (hopefully) - I’m trying to get the new single inline list to write to the Policy Choice Selection table that I created but I’m not having any luck. I’m trying to decompose and recreate the steps in the data editor but it looks like you created the custom action to write to the same table in a single value column? Am I seeing that right?
EDIT: I straight up cannot get the selection from the inline list to write to the Policy Choice Selection table
EDIT 2: I think I got it… the custom action is writing the policy number to the SV column, which in turn writes to the Policy Choice Selection table. That way, the action only chooses the policy once and the clear action (which clears from the table) then only clears the policy once as well???
EDIT 3: Total stream of consciousness above sorry about that. I figured it all out (thank you again!) but I need it to pull the specific dose for each medication, based on the color chosen, not the title (ex: Gray / 3-5kg / 6.5-11lbs). Using the dynamic filtering technique from before would work but the end user won’t choose the med, it it already populated in the policy itself. Is that possible?
Sorry for the delay. Finally looking at your question.
Glide allows you to set column values through single relations. As such, a single value column that is set to retrieve a ‘whole row’ is really the same as a single relation, but without the need to specify columns needed to establish a relation.
Can you expand on this some more. Just trying to understand it better. So when a user selects a specific policy, it will select the matching row in the PEDS table. I guess I’m a little confused on where the choice component comes into play once that’s selected. Lets take the example below. If I select policy 4301, it makes that row visible in the PEDS tab. Then on that row I select the color White. What’s supposed to happen then? Is it supposed to match up with the row that contains White in the LBRT Colors column to the right…and I assume all of the related columns to the right of that? Where do the Color columns at the end of the table come into play? Is it safe to assume that all of those color column aren’t really related to the policy?
I’m just trying to understand if the color columns are related to the selected policy for, or if its really independent data. I’m wondering if it would be better to have it in a separate table if it’s separate from the policy.
Thank you for your response! I apologize for the layout of my data tables - I know it looks confusing. I usually throw stuff up there to see what works and delete what doesn’t but occasionally (i.e. - frequently) I forget and stuff just stays there. I was planning on using the “Find all uses” function to remove stuff before you saw it but… I forgot
So, here goes:
This is a little bit difficult to articulate so bear with me. In EMS, for the most part, there are two levels of prehospital provider: EMT and paramedic. EMTs can do some of the things, and administer some of the same medications, as a paramedic. Paramedics can do, and give, more. There are typically two types of patients: adults and pediatrics. So, as you’ve probably noticed, the ALS and BLS tabs are remaining static because the patient type is an adult. The only variable in those is WHO can give WHAT. With pediatric patients, the same medications can be given but, because of the child’s physiology and (in)ability to metabolize medications like adults can, the vast majority of what they are administered is based on their weight. Here’s an example:
In our Seizure policy, you can see that adult patients can be give two different doses of Midazolam based on the route of administration. Pediatric patients can be given the same medication by the same routes, but because the dose is weight based, a calculation must be made to determine what it is (first, their weight must be converted from pounds to kilograms then, to determine the appropriate dose, their weight in kgs is multiplied by a specific dose, usually 0.1 mg / kg - but sometimes not). We have resolved the need for our providers to perform these calculations under duress while at the patient’s side by providing all medications and their respective weight-based doses in a Calculation Chart, which crosses the medications and the patients general weight or height as determined by a standardized Length Based Resuscitation Chart (below - and, this is where the COLORS come in)…
So, the long answer to your short question is: when WHITE is chosen, the end user needs to see the calculated dose for a specific medication based on the dose as it’s included in the WHITE column.
No. Only the color that the end user has selected.
There are nine distinct colors, all related to a patient’s specific weight and / or “length” (crown to heel) on the LBRT
This is correct - they are related to the calculation chart not one specific policy. When I was first trying to make this happen, I just started copying and pasting data into the two tables, “PEDS Patient Management” and “PEDS Calc Chart,” because I was having difficulty making it work the way I needed it to.
What I started doing last week, which seems to be working (at least for now), is creating individual inline lists for each color then using conditional visibility based on the users color CHOICE, then filtering the applicable lists based on the medication in each policy. It’s cumbersome, by no means streamlined, totally not sexy in its appearance in the data table, and I’m hoping that there won’t be noticeable slowdown because each policy will have multiple conditionally visible and filtered lists, so
I tried this but I couldn’t get the CHOICE component to write to the column where I needed the data. Guaranteed I was doing it wrong but I think it was because I was trying to use the Dynamic Filtering Technique
OK, I’m still trying to completely wrap my head around this. If you could create a Loom video to show what you are trying to get, that might help me. I’m a visual learner. Maybe include a general idea how what the screen should look like when working correctly.
I made a couple of changes in the copy that I have that helped me out a little bit. I think my changes kind of broke how everything was displayed on the PEDS tab, so I fixed that to the best of my knowledge. I also moved all of the inline list titles to rich text components, so the text is formatted correctly. That helped me a lot to get a better understanding of how the screen should look.
I think I kind of get what your goal is. Just trying to put all of the pieces together. As far as the medications and the colors, I think I kind of get what your goal is. Just trying to put all of the pieces together. I chose policy 4401 which has Aspirin as a medication. I realize that it says ‘NOT PERMITTED’ under all colors, but I just needed to see a listed medication in the Medication 1 column that matches a listed medication in your Medications column at the end of the table.
Lets just assume that aspirin was a permitted medication. I’m assuming you are trying to see something on the PEDS tab that shows the medication along with the dosage for that medication as opposed to only the medication as it is right now??? In reality, should it list Aspirin, but also say NOT PERMITTED?
And, maybe I’m still misunderstanding something, but you list columns with medication1,2 3, etc and dosage for each one.
How exactly do those number medication columns relate to the medication/color coded dosage at the end of the table? Or is the intention to ignore the dosage in the numbered medication column and instead use the chart?
And can you clarify what it mean when you list a medication multiple times in the charge. I assume it’s based on the Indication, but I’m not sure how that should be ultimately displayed. I guess overall, I’m trying to get a better idea of how the screen should look once a Policy and LBRT are chosen.