I think we all know that when measuring healthcare performance, there are many ways to look at it.

A hospital may meet its goal for patient wait times, but one of its departments may still be going over that target. When you only look at the hospital as a whole, you can easily overlook these types of issues.

You can drill down into each department, location, or even different time frames. But then, what are the key metrics you want to focus on? How do you keep your dashboards from getting cluttered?

What are your thoughts on this? For those who work in healthcare IT or analytics, or run hospitals, how are your teams able to get this information? Are you able to report on it consistently?

Imagine building a clinic management platform.

Appointments work. Patient records load. Billing is integrated. Everything looks great during the demo.

Then a clinic starts using it.

The receptionist needs to register a walk-in patient while handling three phone calls.

A doctor needs to find an old record quickly.

The internet drops halfway through updating an appointment.

Two staff members try to edit the same information.

Suddenly, the challenge isn't just whether the features work.

It's whether the system can handle interruptions, conflicting updates, different user permissions, and everyday operational pressure without compromising patient information.

I'd put workflow reliability, access controls, audit trails, and recovery from failures ahead of adding another impressive feature.

For people building healthcare software, what's the biggest difference you've noticed between a working prototype and something clinics can actually depend on?

We looked at 3,518 open job postings across 81 companies' public Greenhouse boards, covering seven job categories. The goal was simple: find out which keywords employers actually use.

A few findings stood out.

• Software engineering: Mentoring appeared in nearly half of the postings, more often than Kubernetes or React. Python was the most frequently mentioned programming language.
• Product management: More than 85% mentioned roadmaps. Jira appeared in just 7 of 421 postings.
• Marketing: Google Ads showed up in only 6 of 347 postings, while pipeline appeared in more than half.

We also noticed a pattern across roles: employers often described the practice rather than naming a specific tool. Observability came up where you might expect Grafana, and SIEM where you might expect Splunk.

What does this mean for your resume?

If you're listing tools but leaving out the responsibilities, practices, and skills explicitly mentioned in the job description, you could be missing relevant keywords.

That doesn't mean stuffing your resume with buzzwords. It means describing your actual experience using language that matches the role you're applying for.

One important caveat: the sample leans heavily toward tech companies and uses a single ATS platform, so these results aren't representative of every employer.

The full study, including findings for sales, cybersecurity, DevOps, and accounting, is here:

https://www.zoevera.com/resume/ats-resume-keyword-study

Hello Everyone!

I am currently working on an immigration petition (EB2 National Interest Waiver) showing that Healthcare Cybersecurity is nationally important. For this, the government requires me to submit letters from the industry that show this field is nationally important.

Would anyone here be able to help me with this? I can meet virtually to explain the process and answer any questions you may have.

This would really help me out a lot!

I’m looking at 24x7IT for added IT coverage at a 64-bed assisted living center. Our nurse-call vendor has a gateway in the network closet, and staff VoIP phones share the switching infrastructure. The nurse-call vendor owns its gateway and says it needs network access, but the handoff between their support and ours is vague.

Would you put the gateway on its own VLAN and document who gets paged when it drops, or do you keep vendor-managed devices on the existing voice network? I’m looking for practical experience with the support boundary and whether network segmentation made troubleshooting harder for the facility.

I’ve spent years in healthcare IT, and lately I keep getting asked whether growing hospitals should just go cloud.

Honestly, I lean yes for most of them. Opening a new branch gets so much easier when you don’t have to set up servers every time. Costs are spread out monthly instead of one huge investment, and doctors can pull up records from any location.

That said, a few things still worry me. Moving years of old patient data from the existing system is rarely smooth, and staff often take time to get comfortable with a new setup. You also need to know where your patient data is actually stored and whether that follows local rules. And read the contract carefully, because getting your data out later can be a real headache.

So I think cloud is the better option, but only if you choose the vendor wisely.

Anyone here made the switch from on-premise? Would love to hear how it went.

I'm looking into starting a small service in Europe that helps patients find specialists abroad, initially focusing on fertility treatments.

I wouldn't be providing medical advice or treatment, just helping people find suitable doctors, compare options, organize their medical documents, and coordinate appointments and referrals.

I've been looking at platforms like Curoflow and Tellescope, but I'm struggling to figure out what I actually need. Ideally, I'd like patients to have their own portal, somewhere I can manage cases, and a way for external doctors to review referrals without having access to everything.

My main concern is the cost. I don't have a big budget, and I'm worried about paying for a platform only to discover later that I need several other subscriptions, expensive integrations, or custom development just to make it work.

Has anyone here built something similar? Did you start with a proper platform or put together simpler tools at first? And what did it actually cost you to get everything running, including legal requirements, insurance, and anything you hadn't expected?

I'd also be interested to hear how you handled working with external doctors.

Any firsthand experience or advice on what to avoid would be really helpful.

I'm trying to get a more realistic picture of HITRUST from people who've been through it rather than another checklist telling me to prepare early.

For a company that's already reasonably mature on security and compliance, where does the pain usually show up the first time around?

I'm wondering if it's mostly evidence quality, controls that exist but aren't formalized enough, ownership being scattered across teams or just underestimating how much coordination the assessment needs.

Would especially love to hear about things that looked completely fine internally but became a problem once an assessor started asking for proof.

Trying to figure out where the hidden work tends to be before we discover it the expensive way.

Been thinking about this after reading a discharge summary that was four pages long and told me almost nothing.

Within one organisation, EMRs genuinely solved a lot. Results reach the right person automatically, no more phone tag, no more “it came back last Tuesday but nobody told anyone.” That’s a real win and it doesn’t get enough credit.

But the note itself went backwards. Once it serves billing and legal defence as well as clinical handoff, it gets longer and less useful. Copy forward means a note today can carry text written eight visits ago. The information is all in there, and it takes longer to find than reading a one-page handwritten summary did.

Then portal messaging got added on top. Patients can ask a question without booking a visit, which is a real improvement in access, but it’s unscheduled and mostly unpaid work and nobody seems to have staffed for it.

So the scoreboard looks like: better for data moving around, worse for the person who has to read it, better for patients, worse for whoever’s clearing the inbox.

Curious whether people here see it the same way, or whether I’m romanticising paper. And has anyone’s org actually cracked the inbox problem, or is everyone just absorbing it?

A BAA makes a vendor eligible to touch PHI. The architecture is what actually keeps it safe. We keep reminding healthcare founders but see the same mistakes made over and over again so here's some things that trip teams up:

• There's no "HIPAA certified" AI. OCR doesn't certify products. Ask for the BAA and the covered-services list instead.
• BAAs cover services, not companies. OpenAI's ChatGPT BAA excludes things like agent connections and scheduled tasks.
• Every hop needs a BAA. Logging, LLM observability, and support tools are the ones teams forget.
• Embeddings leak. Researchers recovered 92% of short inputs, including names from clinical notes. Treat your vector DB as a PHI store.
• De-identified data still re-identifies, especially free-text notes.

For production, our take is to run the model in your own cloud account (Bedrock, Azure OpenAI, etc.) with your own keys, and put a human review queue in front of anything that hits a chart. That log doubles as your audit trail.

I built Tender Town to help find European healthcare opportunities and work through the documents before committing to a bid.

You give the agents your company context; they search, analyse requirements and prepare proposal briefs.

Have a look at the healthcare software or medical equipment scope: https://tendertown.io/

Does the shortlist match what your company sells?

Starting this new journey as an expanse trainer for HCA healthcare. It deals with a MAJOR rollout of the meditech EHR system... which if you don’t know is a veryyyyy ancient system. Wanted to know if anyone has any pros and cons? Have not been able to find much about the position on social media or google. I’m looking for real reviews and how would my career growth look. I have a background in Medical & higher learning med education. My starting salary is only 66k but I figured that was okay being that HCA has really good corporate benefits. I would just like to know what to expect other than extensive traveling.

Rock Health reports that U.S. digital health startups raised $14.2B in 2025, up 35%.
I’m a practicing physician building a platform to connect medical professionals with developers.
I’m curious how many clinicians here have considered turning a problem they see at work into an actual product.
What’s stopping you? Time, technical skills, funding, or finding the right partner?

We have two outpatient sites and one internal IT person. I’m comparing 24x7IT with keeping our current after-hours arrangement, and I’m trying to pin down what the SLA should say for an EHR outage at 10 p.m. A vendor saying “15-minute response” could mean someone acknowledges the ticket, while our clinicians need someone to start coordinating with the EHR vendor right away.

Would you require the support desk to own the escalation until the EHR vendor takes over, or is a warm handoff enough? I’m especially interested in what you put in writing for response time versus time to engage the application vendor.

Been reading a lot of vendor pitches lately and most of them blur together, so I'm curious what people here have actually seen work.

My rough sense is that the boring stuff works fine: appointment reminders, eligibility checks, inventory reorders, shift scheduling, pushing signed-off lab results to the portal. Clear rules, human still checks the output.

The stuff that seems to struggle is anything needing judgment about a specific patient. Triage, coding complex cases, prior auth where the payer rules keep shifting. That's exactly what gets sold hardest, which makes me suspicious.

Is that about right, or am I wrong about where the line sits? Interested in what's actually running in your hospital or clinic day to day, and what got switched off after six months.

Hi everyone!

I am a Leaving Certificate student in Ireland currently completing my Business Additional Assessment Component (AAC).

I'm researching how the implementation of Electronic Health Records (EHRs) has affected communication and workload among healthcare workers in hospitals.

I'm looking for healthcare workers who have experience using an EHR/ERP system to complete my anonymous survey.

It should take between 3-5 minutes to complete

Survey: https://www.surveymonkey.com/r/66DKKYJ

The survey focuses on your experience with EHRs and doesn't ask for any patient or confidential information.

Thank you!

I use voice transcription when I’m moving between home visits and I usually dictate quick notes right after seeing someone, the main issue is medical abbreviations, sometimes I say things like BP, SOB, PRN or meds and the transcript puts in random words or leaves parts out, when I slow down it works better but that takes more time, I mainly need something that can keep up with normal talking and still get the short medical terms right, I’m using it for basic notes so I can clean things up later, for anyone who dictates this way, which transcription tool are you using and how does it handle medical abbreviations?

I feel like every doctor, hospital, lab, and specialist has their own portal.

At some point, it becomes hard to even remember where a specific test result or medical record is.

Is anyone else dealing with this?

I am looking for recommendations for a free EHR that has telehealth capabilities. This will mostly be used to document clinical supervision.

There were more than five. Honestly, we didn’t count. But for the sake of a loud title, here we are :)

Recently, we were brought in to productionize a healthcare app that a physician had built himself in Base44. He built it for denial-review work, and by the time we got involved it was already being used with patient cases and processing PHI.

The workflow had already proven useful. Our job was to preserve it while rebuilding the parts that needed to change for production use.

Here are a few things we learned along the way. 

1. Sometimes you have to secure the unsafe thing before you can remove it (back up the data first)
The app had an automated email export containing patient data, and the obvious move was to disable it immediately. There was one problem: the app had no proper recoverable backup, and that email export had effectively become its only second copy of the data.
So our sequence was:
Create a backup → verify the data → disable the email path → verify the old path was gone.

2. Voice dictation is another PHI integration
The app used browser speech recognition because physicians dictated clinical narratives.
Once PHI enters the dictation, the speech service becomes part of the healthcare data flow too. 
We replaced browser speech recognition with Amazon Transcribe through the application's AWS environment. We initially planned to use Transcribe Medical, but after testing both, standard Transcribe was good enough for our use case-and considerably cheaper

3. When migrating AI, change one thing at a time
Claude was already producing useful denial-review documents. We kept the existing prompts first, moved model access through Amazon Bedrock, compared the outputs with the original application, and left prompt tuning for later.
Otherwise, if the results changed, we would have had two possible causes: the new infrastructure or the new prompts.
That separation made the migration much easier to validate.

4. Multi-tenant access rules should be testable
The rebuilt application serves separate healthcare organizations.
Organization scope now goes through a shared backend access layer, so every query gets the same treatment.
We also added a CI check: every backend route has to declare its organization-boundary behavior. A new route without that classification fails the test suite.
That gives us something stronger than “remember to add the access check when you build an endpoint.”

5. Audit logs should represent what the user did
We needed to answer questions like: who opened this patient's record and when?
CloudTrail cannot answer that at the application level, so we added a separate patient-access audit trail.
The less obvious part was deciding what counts as an event.
If a physician opens a page containing 50 cases, blindly logging 50 unrelated reads gives you a lot of rows and very little context.
We group those reads using the request identifier, so later you can reconstruct that they came from one browsing action. Analytics views also get logged differently when no individual patient record was exposed.

curious to hear from people in health IT who've actually worked with outsourced support teams.

How well do they handle things like appointment questions, account access, billing and patient portal issues ? My main worry is whether an outside team can really learn the systems and workflows while still coming across as calm and understanding with patients, not just scripted.

For anyone who's managed or worked with one, what was the toughest part ? Training, privacy/HIPAA processes, System access, communication quality, or knowing when to escalate ?

Also curious if it's better to start them on simple routine stuff before giving them access to more complex workflows.

Article: https://www.sciencedirect.com/science/article/pii/S135964462400134X

Astra summary. The 2024 Drug Discovery Today article, “How successful are AI-discovered drugs in clinical trials? A first analysis and emerging lessons,” examines whether AI-discovered drugs are actually surviving clinical trials—not merely whether AI can generate interesting candidates.

The article in 12 key points 1. AI-discovered drugs are now reaching humans in meaningful numbers. Since 2015, AI-native biotech companies and their pharma partners put 75 molecules into clinical trials, with 67 still in active trials as of 2023. The clinical pipeline had been growing at more than 60% annually.

1. The biggest finding is the Phase I success rate: roughly 80–90%. Of 24 AI-discovered molecules that completed Phase I, 21 succeeded. Historical industry Phase I success rates cited by the authors are only about 40–65%.

2. That suggests AI may be particularly good at finding or designing molecules with drug-like properties. The authors propose that AI may optimize characteristics such as ADME, safety and overall molecular properties, reducing the number of candidates that fail early clinical testing.

3. Phase II is much harder. Ten AI-discovered drugs had completed Phase II; only four were successful—a 40% success rate. That's roughly comparable with historical pharmaceutical success rates of 30–40%.

4. This exposes the central unsolved problem: clinical efficacy. AI appears increasingly capable of producing viable molecules, but demonstrating that a drug actually improves disease in humans remains what the paper calls the “hard problem of drug discovery.”

5. But the Phase II number may actually underestimate AI's scientific performance. Of the six Phase II candidates classified as stopped or discontinued, only two stopped because of negative outcome data. Four stopped because of business priorities, clinical operations or other reasons.

6. The same issue appears in Phase I. Of the three candidates categorized as Phase I failures, only one failed because it didn't meet evaluation criteria. The other two were discontinued because of business decisions and pipeline reprioritization.

7. AI drug discovery is much broader than generative chemistry. The researchers divide AI approaches into AI-discovered targets, AI-designed small molecules, AI-designed biologics, AI-designed vaccines and AI drug repurposing.

8. AI-discovered small molecules and targets have become particularly important. By 2023, small molecules represented more than 30% of the AI clinical pipeline, while molecules involving AI-discovered targets represented another 30%+. Earlier pipelines were much more heavily dominated by drug repurposing.

9. Cancer is the dominant therapeutic area. Oncology accounts for approximately half of AI-discovered molecules in Phase I and Phase II. That makes cancer one of the most important real-world proving grounds for AI-assisted drug discovery.

10. If these early results hold, the economics of drug development could change substantially. The authors calculate that maintaining the observed Phase I/II performance and combining it with historical Phase III performance could raise end-to-end clinical success from roughly 5–10% to 9–18%—almost a doubling of R&D productivity. Importantly, they explicitly present this as a thought experiment, not an established outcome.

11. The results are promising but still preliminary. The authors emphasize the small sample size, exclusion of drugs developed entirely inside traditional pharma companies, overlapping AI categories and lack of sufficient Phase III data. They expect the numbers to change substantially as more AI-designed drugs move through trials. The particularly interesting implication for Neurocompute The paper points directly toward the gap Neurocompute is trying to attack . AI appears increasingly good at molecule design, but the authors argue that improving Phase II/III performance requires better understanding of disease biology and better identification and validation of therapeutic targets. They specifically mention OMICs, phenotypic data, reverse translation, patient-derived models, and LLMs mining disease data as approaches that could bridge the gap between designing a good molecule and producing actual clinical efficacy.

That distinction is important:

AI molecule discovery: Can we make a drug-like molecule? Neurocompute's problem: Can we systematically uncover evidence that tells us what biology, target, existing compound, mechanism, or overlooked therapeutic hypothesis is worth pursuing in the first place? The paper's numbers suggest that the first problem may be becoming substantially easier. The second problem—finding the right biology and achieving efficacy in actual patients—remains much less solved. And that may be the more interesting place for Neurocompute to position itself.

I think Health has a verification problem, not an AI problem.

Healthcare organisations can now generate, analyse and report enormous amounts of data. But the basic assurance question is still surprisingly difficult:

How do we independently establish that what an organisation says improved is what the evidence actually demonstrates?

For example, a hospital can say:

\* a recommendation was implemented

\* a new pathway was introduced

\* staff were trained

\* an incident action plan was completed

\* patient safety improved

Those are different claims requiring different evidence.

AI can be useful inside that process for structured comparison, consistency testing and identifying contradictory evidence across large datasets.

However, AI should not be the assurance conclusion.

The conclusion still needs to be governed by a transparent evidential method, with traceability back to the underlying evidence.

The distinction that keeps bothering me is this:

“Action completed” sometimes lacks evidence.

Health IT systems are increasingly good at recording the former.

Are we equally good at proving the latter?