That’s fine but most are using LLMs and it’s making this less fun for mentors. If they added that section on their own, it’s fine but they didn’t.
@r0bby I really like your honest and direct feedback and it is genuinely helpful to me , thank you for the guidance!!!
1 Like
Hi @r0bby, now that I’ve submitted my proposal, I’d love to use this time to deepen my understanding of the project beyond what I wrote.
I’m curious — if you were approaching this project from scratch, how would you think about it? Specifically: • How would you move from the high-level security architecture down to concrete, implementable components? • How would you decide on boundaries, responsibilities, and what to build first? • What early trade-offs or pitfalls would you actively watch out for?
Even a brief perspective from you would be genuinely valuable.
Thank you!
have a peek
Hello @kishansinghifs1 thanks for your proposal which seems good… It’s important we take this from scratch and you also understand the architecture of the project. While this project is being ported to Laravel atm I think we might need to upgrade a few deps to ensure we are up to date which might solve part of the security concerns by this tool.
Also For this project, the most important part is not just running tools, but proving that critical EHR workflows are assessed in a way that reflects real authorization, PHI exposure, and clinical-data integrity concerns. So things like who should access what is vital as well down the rabbit hole .. e.g How will you define which parts of the EHR app are PHI-sensitive? How will you model one MU workflow as concrete testable security assertions?
@sunbiz might have other suggestions perhaps .
Hi @muarachmann, thank you for taking the time to answer this!
Regarding the dependency upgrades, that makes sense upgrading them will resolve some of the existing security concerns, and I believe staying up to date with dependencies is essential,therefore I have already added in proposal for composer audit in pipeline that will keep catching new vulnerabilities going forward as packages evolve.
For the PHI classification and the MU workflow test assertions, I think I need your guidance on both since they are the foundation everything else builds on and getting them wrong would affect the entire pipeline. I want to make sure the PHI criteria is defined correctly and that the test assertions reflect real clinical authorization concerns and not just surface-level checks. I plan to work through both of these carefully during the community bonding period with your help.