brown

If LLMs live up to their potential, then they should be able to rewrite language runtimes to eventually be as fast or faster than systems languages. "Sufficiently intelligent compiler" and whatnot

It’s true that many providers need a custom solution for their unique workflows, and the one-size-fits-all EHR is often a myth. The problem is that many EHRs try to solve this with customizations, which can be expensive and still feel like a compromise.

On the other hand, when a team tries to build their own tools, they quickly realize they have to build a ton of compliance and interop code they never wanted to touch in the first place. That’s why open source platforms that handle the core infrastructure, like Medplum, HAPI, or OpenEMR, can be such a good starting point. They get the team 90% of the way there, so they can focus on what really matters: building a great UI/UX for their users.

I don’t think providers truly want to go back to pen and paper, but they are looking for a better way. They can see the promise of what the solution could be, but they just haven't experienced it yet.

Disclaimer: I work for Medplum.

given AI seems like a winner takes all type market

Unfortunately for OpenAI and Softbank, it seems like AI will not be "winner take all", and may actually be quite commoditized. It's as easy as choosing a different model in a dropdown in Cursor or whatever your tool of choice.

RDAP replaces WHOIS, offering a more technologically advanced way to discover the domain is protected by privacy services.

Learning assembly was profound for me, not because I've used it (I haven't in 30 years of coding), but because it completed the picture - from transistors to logic gates to CPU architecture to high-level programming. That moment when you understand how it all fits together is worth the effort, even if you never write assembly professionally.

Love Postgres, but major version upgrades remain the one genuine pain point. One misstep and you're in backup-restoration hell. Solid guide.

There are two interesting "safety nets" at play here: the classic "Nobody ever got fired for choosing IBM" principle (where ubiquity creates an implicit guarantee of continuity), and a less visible but equally powerful one where certain open source tools become such fundamental infrastructure that they're essentially "too critical to fail." Think curl, gpg, or apt - most users never directly interact with these, but they're so deeply embedded in the internet's fabric that the ecosystem ensures their maintenance. One heuristic I've found helpful is looking at major corporate adoption patterns - it can be a decent signal for identifying which tools fall into these categories.

I highly recommend js13k (https://js13kgames.com), an annual game jam where your entire game must fit in 13 kilobytes. The tight size limit forces you to get creative with optimization - think procedural generation, custom minimal engines, and code golf techniques that actually matter. While the games might be "useless" in a practical sense, you'll learn more about low-level JavaScript optimization than from most serious projects, all while being part of an incredibly supportive community that loves sharing tricks and tips.

js13k is a game jam competition. Make a game that fits in a 13 kilobyte zip.

"The thirteenth, anniversary edition of the online js13kGames competition starts… NOW! Build a Web game on a given theme within the next month and fit it into a 13 kilobyte zip package to win lots of cool prizes, eternal fame, and respect!"

Medplum (https://www.medplum.com/) | Founding Developer Experience Engineer | SF | Full time

Medplum (YC S22) is an open source, API first, healthcare developer platform. "Headless EHR", we take care of the security, compliance, and regulatory burdens of healthcare software development. Well funded and growing fast.

We're hiring an amazing Dev-Ex / Dev-Rel engineer to delight customers, build sample apps, and promote the Medplum platform.

Tech stack: TypeScript, React, Node.js, AWS

Learn more: https://www.medplum.com/careers/devex-engineer

4 players: https://codyebberson.github.io/pong-wars/

“Training costs scale with the number of researchers, inference costs scale with the number of users”.

This is interesting, but I think I disagree? I'm most excited about a future where personalized models are continuously training on my own private data.

My favorite URL oddity has to be "id.me" for U.S. Citizen identity services.

Seems a bit odd to use a Montenegro domain, doesn't it?

The domain name made me curious: http://10x.engineer/

"404 Not Found: 10x Engineers aren't real"

Well played.

For anyone who wants to slow the development of AI, copyright is the soft underbelly to go after.

Thanks! We're a healthcare SaaS provider, mostly engineers who are neither musicians nor marketers.

As a quirky marketing exercise, we used ChatGPT to write parody lyrics for a song about ONC g.10 compliance to the tune of "Like a G6" by Far East Movement.

We then paid $50 on Fiverr to record it: https://soundcloud.com/medplum/medplum-g-10

The whole thing took about an hour of effort. It was easy to be fun and lighthearted about it because "AI wrote it" and we didn't experience the normal fear of publishing.

This is extremely niche marketing, but our core audience loved it. Great bang for buck.

I think that's more about asset sizes and loading times than rendering capabilities.

Not sure why Dwarf Fortress is on the front page, but I will always upvote.

If you're intimidated by ASCII visuals, consider wishlisting the graphics release, scheduled for Dec 6, 2022: https://store.steampowered.com/app/975370/Dwarf_Fortress/

Thanks!

Haha, yes, but someone got there first, with a now abandoned project.

One of the most complex Medplum projects is a large multi-party lab integration. We followed the US Core Lab Profile (https://hl7.org/fhir/us/core/StructureDefinition-us-core-obs...). We not only represented the labs results in FHIR (ServiceRequest, Observation, DiagnosticReport), we also represented the full lab catalog (ObservationDefinition, ActivityDefinition, PlanDefinition).

Time after time, stakeholders would raise new requirements -- how do we model pregnancy status? how do we model multi-step lab tests? how do we model contextualized reference ranges? Time after time, the FHIR schema had a clear answer.

That goes a long way to simplifying and streamlining multi-party integrations, and cuts out a lot of wasted time trying to reinvent everything from scratch.

Redox shines in complex multi-party interoperability projects. They have an impressive number of pre-existing integrations with providers and payers. They also provide professional services to navigate last mile connectivity details. If you need to integrate with a 3rd party immediately, then Redox is a great choice.

Medplum has a number of interoperability features: FHIR and HL7 endpoints, and developer tools to store and manipulate the data as needed. But our integrations are more "DIY" and developer focused.

At this point, everything running in production is 100% open source, and we don't have any plans for proprietary code.

We use FHIR R4. For ONC g.10, we are targeting US Core 5.0.1, USCDI v2, SMART App Launch 2.0.0, and Bulk Data 2.0.0.

Lab integrations and ePrescribe are interesting -- in our experience, the complexity is less technical, and more about getting access to the various systems. We work closely with our early customers on these partnerships. Our ultimate goal is to have turnkey integrations, so it's just a matter of entering connection details and credentials.

Thanks for the kind words!

Our goal is to provide a comprehensive experience that spans both front end and back end. In practice, we're focusing on a rock solid server first. At present, our front end components are best used for rapid prototyping and internal tools. Developers who want to create highly custom and pixel perfect designs will probably opt to use their own front end stack.

We do not currently support the StructureMap $transform operation, but we are actively working on it to support conversion to/from CCDA and other FHIR versions.

We have the utmost respect for HAPI, Google Health API, and all other FHIR servers. We believe that they are all contributing to cleaner and more interoperable data.

One key difference between the Medplum server and other FHIR servers is that it is designed to be use as a complete backend, not just a data store. That includes supplemental API endpoints for end-user auth and account management, automation ("Bots" for "if this, then that" style automation). The goal is that a developer should be able to create a complete digital healthcare experience with only a statically hosted website -- no additional servers required. In our experience, HAPI and Google Health API are used more like a database, where you run additional servers in front. We believe that providing a more comprehensive server lowers the barrier to entry, and reduces the maintenance burden for digital health providers.

Looking forward to hearing from you!

Thanks. You might be the first person outside of the Medplum team to look at that file, happy to hear a positive review.

I understand the cynicism. We do believe that providing a high quality open source offering can contribute to solving the problem.

Awesome, thanks for the pointer. I just added it to our backlog for investigation.

Thanks! We all have our HL7 v2 pipe delimited scar tissue.

At present, Bots are AWS-only. We have an active enterprise customer who is exploring porting Bots to Google Cloud Functions. Azure Functions are on the longer term roadmap too.