# data[].attributes.body
If we want to note a reminder that SHIP funds shouldn't be used for x in y strategy- would this note go in the implementation guide (not the financial guide)?

# data[].attributes.body
I generally support this proposal, but I'm curious if others are concerned about being able to justify a non-approved expense if it's not clearly noted as unallowable in the financial guide. I also worry a little about keeping consistent with approvals when fewer items are on the list of unallowable.

# data[].attributes.headline
Can we clarify how both the content staff and the CS's will use the financial guide to provide TA vs GM? I think this will help make roles clearer and/or show how much overlap exists between roles. Maybe even putting these expectations in the guide itself?

# data[].attributes.subject
Can we clarify how both the content staff and the CS's will use the financial guide to provide TA vs GM? I think this will help make roles clearer and/or show how much overlap exists between roles. Maybe even putting these expectations in the guide itself?

# data[].attributes.body
I'm willing to try this, however I'm not clear what has been decided for our TA plan. And I'm worried about my capacity to provide the amount of TA that might be needed.

# data[].attributes.body
Simplify as much as possible sounds great, but I feel there are a few things that are specific to SHIP as unallowable/conditional that should still be included. It seems a bit much to strip it down to bare MDH policy unallowables, and if we did it would be similar to SHIP 5 where things kept getting added as requests came in.

# data[].attributes.body
Pro: Some consistency might be provided with this option. It sounds like this would be a cleaned up and maybe clearer version of what we have?

# data[].attributes.body
I like this proposal and making things simpler. I really like clarifying what is unallowable per MDH / the contract vs what might more of an OSHII / programmatic expense concern. But I'm not sure how this will work for those under $3k expenses, because in terms of TA, thriving communities staff won't know about those until after the money has been spent, at which point we won't be able to have that TA conversation. Am I understanding that right? I'm not sure what to do with those smaller expenses and if we want to just let that go and see what happens?

# data[].attributes.body
With the leadership decision to raise the amount for expenses up to $5000, we know from the CS team that we need at minimum of a scope of work and a goal and we are requiring a project/body of work to be approved before spending attached to that project/body of work happens. For expenses under $5000, what level of information or oversight do staff want before LPH goes and spends their dollars under that amount (if they're not on the conditional allowable list or a service contract)?

# data[].attributes.body
One pro: Local SHIP are familiar with this format. With so much changing, it might be welcomed.

# data[].attributes.body
I'm also comfortable trying this but I do think that something needs to take the place of the conditional allowable. For instance, labor was not allowed in the past but it is conditionally allowable if linked to a PSE change, etc. If we remove any guidance on things that fall under conditional allowable, I fear that LPH will be more confused about what they can spend money on.

# data[].attributes.headline
Currently I hear feedback that some LPH SHIP folks want even more of a list of unallowable... There are so many different ways people approach SHIP and their work, it's tough to determine one approach that'll will fit with all approaches. Maybe this is a "clear is kind" kind moment and not change much in the financial guide for now.  Then revisit a year into SHIP 6? 

# data[].attributes.subject
Currently I hear feedback that some LPH SHIP folks want even more of a list of unallowable... There are so many different ways people approach SHIP and their work, it's tough to determine one approach that'll will fit with all approaches. Maybe this is a "clear is kind" kind moment and not change much in the financial guide for now.  Then revisit a year into SHIP 6? 

# data[].attributes.body
I am also open to this, and I like it, but when we tried this with SHIP 5 it threw LPH off and we have consistently heard a request for more guidance around what is allowable.

# data[].attributes.body
I am okay with any of these. I don't think its an issue with the specific items. I think what needs to be specified and written clearly is the decision making process to approve or not approve the request. I think the decision making process of what is approved vs not is the confusing part.

# data[].attributes.body
I really like LPH having to have an approved project in their WP before they can spend funds on that project.

# data[].attributes.body
Would it be simpler to focus on allowable instead of unallowable? The unallowable list is much longer. I'm all for short as possible.

# data[].attributes.body
We trust our LPH partners, but we are managing grant funds and need to verify things even if they've been doing SHIP for years. We shouldn't relax on the information we need because they are experienced.

# data[].attributes.body
I like that it exists as a resource. I don't like the layout because I find it confusing and I always worry I'm missing something.

# data[].attributes.body
I like that we allow LPH to spend money on providing incentives to participants for evaluation. I don't like how confusing it is for LPH and how it then leads into lots of work for reviewing financial requests within REDCap.

# data[].attributes.body
I like that the unallowables feel very clear, the guide is overall pretty long though

# data[].attributes.body
It explains the SHIP basics well.  It's hard to explain the differences in settings well.

# data[].attributes.body
I like how much we shortened it from the previous Financial Guide.

# data[].attributes.body
Direction on setting up a local mini grant/RFP hasn't been explained well. which we have talked a lot about before.