91–100 of 163 posts
Adobe has had literally a third of a century to recognize this need and address it. I don't think they're paying attention :-/
Earlier quoted context omitted.
How about fixing the format? Something that is obviously broken and resulting in patient deaths should really be considered a top priority. It's either malice or masskve incompetence. If these protocols were open there would definitely be volunteers willing to help fix it.
Incompetence at this level is intentional, it means someone doesn't think they'll see RoI from investing resources into improving it. Calling it malice is appropriate I feel.
I’d rather have the pdf than a custom tool. Especially considering the tool will be unique to the practice or emr. And likely expensive to maintain. PDFs suck in many ways but are durable and portable. If I work with two oncologists, I use the same pdf. The author means well but his solution will likely be worse because only he will understand it. And there’s a million edge cases.
Earlier quoted context omitted.
Incompetence at this level is intentional, it means someone doesn't think they'll see RoI from investing resources into improving it. Calling it malice is appropriate I feel.
If there is no ROI, investing further resources would be charity work. I don’t think it’s accurate to call a company not doing so malicious.
It seems to me that ignoring the guideline is a physician decision, and when it is ignored (for good or for bad), it is not because the guidelines are not available in json.
The real question is: why is everything stuck in PDFs, and the more important meta-question is: why don't PDFs support meta-data (they do, somewhat). So much of what we do is essentially machine-to-machine, but trapped in a format designed entirely for human-to-human (also lump in a bit of machine-to-human). Adobe has had literally a third of a century to recognize this need and address it. I don't think they're payi…
The OP will be pleased to know that they’re not the first person to think of this idea. Searching for “computable clinical guidelines” will unearth a wealth of academic literature on the subject. A reasonable starting point would be this paper [1]. Indeed people have been trying since the 70s, most notably with the famous MYCIN expert system. [2] As people have alluded to and the history of MYCIN shows, there’s a lot…
The above is a high quality comment with worthy areas to study.
Additionally I would draw your attention to NCCN’s “Developer API” which is not interesting technologically but how it reflects the IP landscape.
Earlier quoted context omitted.
Right, it would make more sense to use HL7 FHIR (possibly along with CQL) as a starting point instead of reinventing the wheel. Talk to the CodeX accelerator about writing an Implementation Guide in this area. The PlanDefinition resource type should be a good fit for modeling cancer guidelines. https://codex.hl7.org/ https://www.hl7.org/fhir/plandefinition.html
This is the comment I was looking for. You would aim to use CQL expressions inside of a PlanDefinition, in my estimate. This is exactly what AHRQ's, part of HHS, CDS Connect project aims to create / has created. They publish freely accessible computable decision support artifacts here: https://cds.ahrq.gov/cdsconnect/repository When they are fully computable, they are FHIR PlanDefinitions (+ other resources like Ques…
I tried to see if HL7 was approachable for small teams, I personally became exhausted from reading it and trying to think how to implement a subset of it, I know it's "standard" but all this is kinda unapproachable.