In my hospital we have ample experience with another technique using polypropylene sheets for defect coverage, popularized in Brazil orthopedics as "Figueiredo's technique", which is in practice an extension of common techinques for temporary closure of abdominal wall ("Bogota's bag").
We put a transparent polypropylene sheet as skin replacement, suture it directly to the skin. We can monitor the wound and its secretions, can cover exposed tendons and bones without immediate doing microsurgical flaps. For example, we can monitor the second intention skin closure with reduced infection and analgesics use, sometimes without needing a graft at all.
Through the years I've worked with several EHR, be helping their development be using it in my practice, and each had it's idiosyncrasies.
In my country there was proposals by the government of integration, but as all things that need coordination, we're nowhere close to sharing information between care centers.
On a city we have several places controlled by the same entity, and they use an integrated EHR, so that a doctor who sees a patient at the emergency department has access to it's full history from the tertiary center, but at the same time the major tertiary/quaternary hospital isn't managed by that same entity and doesn't use the same EHR system, so we can't share information digitally. To make things worse, one system is made in Flash and all computers need to have an outdated Chrome version with the Flash plugin to run it. The other system is made in Java and some form of custom frontend framework, which works ok until it doesn't.
Expanding on this other system made in Java, it's a federal hospital, and we have other internal systems which doesn't communicate with this main EHR, so for example emitting radiology requests need us to copy paste information from two systems (like address, contact numbers), and on top of that those systems aren't connected to the national patient registry, and daily I have residents redoing requests to merge the information, otherwise the requests are made invalid.
I haven't touched on payments, imagine that each health insurance plan have different billings and we need to adapt the reality of what we did to what code better pays and input that in the system, so in practice the records are tailor fitted for each payment system, the actual procedure descriptions change, and we need to remember all that when billing and when treating the patient.
Add on top of that system outage and unreliability, and I haven't even touched much on the UI, which sometimes loses input text data or sometimes we have to input in certain fields order or else the system crashes, or the fact that the tabindex isn't set on all fields and we need to click with the mouse to go to a field.
Personally I've made a simple system for my private practice, while it doesn't have all the functionality, at least I'm the one to blame for it's particularities. I'm still exploring how to better input the clinical data, and I'm starting to think that general systems doesn't work. Each specialty has specific routines which need to be accommodated in the system, be it structured forms, be it clinical image input with annotations and commentary. The field is huge, and we're looking at how to design UX for immediate input and for later review, which sometimes are at odds (for example, a single textarea is easy to input, but how do we parse that data and present a timeline of clinical signs for example?).
I guess we need a Linux of the EHR, something which we can iterate on. I've looked into open source projects, but I don't know if the field is entrenched in inherent complexity or we're all trying to model too generic abstractions on top so that a small team of developers can't comprehend the system.
I should publish some code instead of rambling, but as the field is covered in regulations, I fear not even a code license can disclaim legal obligations.
I really like this, as from an outsider it seems that CL doesn't have a community and the few packages it has are more like building blocks for customizing and implementing you required functionality rather than packaged black boxes. With all those new languages, it appears that the value proposition of CL is dwindling, static checking feels primitive, macros are easily attainable now, and live runtime image manipulation misses the point on the world of short lived containers.
CL has Coalton, which is the implementation of a static type system beyond Haskell 95. Full multiparameter type classes, functional dependencies, some persistent data structures, type-oriented optimization (including specialization and monomorphization). All integrated and native to CL without external tools.
Live image manipulation isn't quite as useful as it once was for runtime program deployment. But it's still a differentiating feature for incremental and interactive development—before you compile binaries to deploy. Tools like Jupyter notebooks don't come close for actual (especially professional) software development.
Unless we have a clear indication, plates are not meant to be removed.
For example, plating children we usually remove the plate as to not interfere with growth, or in some cases a fibula plate can irritate the tendons and should be removed, or in cases of infection.
Functional outcomes seem similar, trough we have a increased rate of malunion, delayed or non-union with nonoperative treatment. We usually indicate surgery if it's an active patient.
I downloaded and opened an CDS for osteoporosis from the link (as a disease in my specialty), I need an API key to view what a "valueset" entails, so in practice I couldn't assert if the recommendation aligns with clinical practice, nor in the CQL provided have any scientific references (even a textbook or a weak recommendation from a guideline would be sufficient, I don't think the algorithm should be the primary source of the knowledge)
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.
You can register for a free NLM account to access the value sets (VSAC). HL7 standards are approachable for small teams but due to the inherent complexity of healthcare it can take a while to get up to speed. The FHIR Fundamentals training course is a good option for those who are starting out.
It might seem tempting to avoid the complexity of FHIR and CQL by inventing your own simple schema or data formats for a narrow domain. But I guarantee that what you thought was simple will eventually grow and grow until you find that you've reinvented FHIR — badly. I've seen that happen over and over in other failed projects. Talk to the CodeX accelerator I linked above and they should be able to get you pointed in the right direction.
I know it's not the same, but in many areas we have this "follow the arrows" system in many guidelines.
For some examples, see the EULAR guidelines with it's fluxograms for treatments and also AO Surgery Reference with a graphical approach to select treatments based on fracture pattern, avaliable materials and skill set.
I think that's a logical and necessary step to join medical reasoning and computer helpers, we need easier access to new information and more importantly to present clinical relevant facts from the literature in a way that helps actual patient care decision making.
I'm just not too sure we can have generic approaches to all specialties, but it’s nice seeing efforts in this area.
Those sites have something like Phoenix LiveView or it's something ad hoc like a simple SSR template engine? Would be nice to have something to handle migrations in the client side code to match the server side API.
Unrelated, all my devices freeze when accessing this page, desktop Firefox and Chrome, mobile Firefox and Brave.
Is this the best alternative to access code ai helpers besides the GitHub Copilot and Google Gemini on VSCode?
I've been using it for a few months (with Starcoder 2 for code, and GPT-4o for chat). I find the code completion actually better than Github Copilot.
My main complain is that the chat sometimes fails to correctly render some GPT-4o output (e.g. LaTeX expressions), but it's mostly fixed with a custom system prompt. It also significantly reduces the battery life of my Macbook M1, but that's expected.
Semantic UI[1] was one I used to use, both the plain CSS one as well as the React version of the library. Version 3.0 is coming (eventually), which has left it a bit outdated for a while, but it's still a solid UI library imho. I have been switching away to Tailwind.
If you want a component library that's going to give you accordions and stuff there's going to have to be a JS implementation involved.
In the early days of bootstrap, it was jQuery. Now, if you want to use bootstrap w react etc, you're going to have to have a third party implementation for the framework you're using (like react-strap if you use react)
Ant and MUI Target react directly which allows them to provide a first party JavaScript implementation for interactive components.
Tailwind is a great example of a JavaScript agnostic solution right now because it's purely concerned with CSS and leaves it to the developer to implement JavaScript stuff on their own. This way you can use things in the ecosystem like react-table and style them with tailwind CSS classes.
There's https://tailwindui.com/?ref=top, from the Tailwind CSS people. They come with a "HTML" mode, which I think means no JS.
But if you need interactivity, on the web it has to be JS, because that's the only thing that can manipulate the DOM. (Edit: To be clear, there are frameworks that COMPILE to JS, so you the programmer don't have to work in JS yourself.) The alternative would be something like a server-updated Canvas where the UI is done outside of the DOM and not in the client, but even that would need some JS shims just to communicate and redraw the Canvas.
If you want to render the entire page serverside and handle all interactions via clicks and HTTP POSTs and such, you still can, of course. That would just be slower for the visitor.
Probably a "JS-lite" approach like HTMX + Alpine would be worth considering?
We put a transparent polypropylene sheet as skin replacement, suture it directly to the skin. We can monitor the wound and its secretions, can cover exposed tendons and bones without immediate doing microsurgical flaps. For example, we can monitor the second intention skin closure with reduced infection and analgesics use, sometimes without needing a graft at all.
reply