FHIR Chat · Family Resident Here...

Stream: social

Topic: Family Resident Here...

Andrew Chang (Apr 21 2021 at 02:25):

Hi all, decided to put this in #social since I am certainly not an implementer and the last time I manipulated any code was when I was changing my banner color on my MySpace account.

I’m a family resident physician a few months away from graduation, recently read up on the developments of interoperability in electronic medical records and FHIR, and I am very intrigued and would like to know more.

The user interface and experience of most EMR‘s that I’ve used feel painfully outdated and unintuitive, and I’m wondering if it would be better to build an EMR from the ground up using FHIR. This way the software can focus mainly on reading and writing, rather than storing, and perhaps make the application much more flexible to changes as the database remains the same.

When it comes to developing software I am a complete novice, but I am very eager to learn how it all works, and wouldn’t mind picking up another language.

I certainly welcome your thoughts and corrections, and if possible hope to connect with someone who might be interested in having a conversation.

Thank you!

Andrew

Grahame Grieve (Apr 21 2021 at 02:30):

There certainly are people doing what you're thinking, and some of them hang out here. However a full EHR is a vast piece of software with almost limitless administrative functionality that is very intricate in terms of regulatory and billing compliance. That's why they feel so outdated.

Also, an EHR is a very flexible piece of software that does all sorts of things very flexibly, and supports very complex workflows with lots of important failure points. That's really hard to make nice - hence, unintuitive. When I was technical lead for a large diagnostic EIS, we got a UX expert in to look at what we had and she said "You have to restrict the number of things your users want to do." Good luck with that...

Grahame Grieve (Apr 21 2021 at 02:32):

but I am hoping that FHIR will make a long term contribution to modularising this problem, so that clinical users can choose their own perfect software without having to run their own systems; this is still a long way away though

Andrew Chang (Apr 21 2021 at 04:03):

I really appreciate your input! Did a quick search to find that you are thought of as the inventor of FHIR!

On regulatory billing compliance, is there any way to separate the two things? Such that a physician can simply do that they do best and billing can assist afterwards? CMS had some welcome changes redefining the levels of outpatient care, I’m sure improvements such as these are in store.

A health IT friend has told me that doctors shouldn’t have to worry about any of the behind-the-scenes or be concerned about building it, but I am increasingly concerned that the increasing complexities on the back end leads to worse inefficiencies and burnout on the doctor’s end.

As far as UX, I agree about restricting number of things to do... I would be open to knowing what would need to be restricted and how it would improve the workflow.

There are docs who have decided to shift to the paradigm of direct pay model where they take no insurance at all and bill services much like a gym membership. If the kind of billing requirements are no more, would there be a way to improve design and function of an electronic medical chart?

To think that in 2003 the American Academy of Family Physicians published an article encouraging family doctors reluctant to adopt an EHR to use MS Word to fill the need... my how times have changed!

Grahame Grieve (Apr 21 2021 at 04:54):

is there any way to separate the two things?

In theory, yes. In practice, not that I know of. There are some services using specialised billing systems here in Australia, so they can have an operational EIS as their choice, but that's a difficult place to be - fragile, and it doesn't take that much load of the admin side, since it's so much more than just billing - 1000s of reporting requirements in all directions, meeting procedural requirements from 10s of different regulators etc

I am increasingly concerned that the increasing complexities on the back end leads to worse inefficiencies and burnout on the doctor’s end.

Absolutely, but that's actually about more than the IT system; it's a property of the system as a whole, so naturally, it manifests in the IT system too.

Josh Mandel (Apr 21 2021 at 04:54):

I think what you're describing is exactly the right thought exercise: how could software systems help you care for patients if billing and administrative responsibilities could be set aside? I'll say that from my perspective, there's significant opportunity for software to automate what's routine, and help you focus your clinical time -- but what do you see as the most important areas for focus? Answers will vary significantly by speciality, and more by individual.

Lloyd McKenzie (Apr 21 2021 at 15:44):

One of the challenges is that as billing moves from fee-for-service to value-based-care, the 'clinical' aspects become more and more billing-relevant. Also, things like prior authorization, payer documentation requirements, etc. all often impact on data that needs to be present in the 'clinical' side of the system. Finally, even when separated, coding for billing is fundamentally driven by what information a clinician captures in delivering clinical care - which means the folks who do the billing portion will exert pressure on the clinical side to ensure they have what's needed to bill correctly (and maximally...)

That said, FHIR offers some opportunities above and beyond building your own EMR from scratch - which as Grahame points out, is a significant lift, though how hard it is can vary significantly by country. (In the U.S., the regulatory and payment burden are probably highest.) SMART on FHIR and CDS Hooks offer the opportunity to build interfaces and supports into EHRs via externally authored services. This might give you the opportunity to design views to display and capture data that are more meaningful and useful to your workflow than those present by default. You can also iterate them more quickly than you could hope for changes to underlying EHR configuration. Whether your hospital/clinic will be amenable to running your custom SMART interfaces or hooks services is a question you might consider as you look at your job offers post-grad. (And if you don't want to do the coding yourself, pairing with one or two recent tech school graduates isn't a horrible plan either.)

Grey Faulkenberry (Apr 21 2021 at 16:53):

So, I will preface this and say that I'm completely biased towards Flutter and Dart. I'm a MedPeds physician completing my clinical informatics fellowship, and I think I was driven into informatics for many of the same reasons you've mentioned above. There's some dude named @John Manning that likes to give presentations about Flutter (free, open-source, well documented SDK from google, let's you run natively in iOS and android, transpiles to js for web, and is in beta for running natively on desktop - so for those of us with not enough time to get good at lots of programming languages, it gives good flexibility. Plus it makes AMAZING user interfaces). He gave a presentation that one of my colleagues attended, and she told me about it, and I thought it was worth checking out. Fast-forward a year and a half, I've written a number of FHIR libraries in Flutter, all freely available and open source (https://pub.dev/publishers/fhirfli.dev/packages, https://github.com/MayJuun/fhir). I somehow got stuck working with John, who luckily is actually a pretty decent developer, ER physician, and youtuber (https://www.youtube.com/channel/UCZjgGDkKv6zVsRxJeZGWxqQ). He's created a number of tutorials at this point, around general Flutter, healthcare apps using Flutter, and then about our open-source collaborative FHIR-FLI (https://www.fhirfli.dev/). We're just scratching the surface, but we welcome anyone that wants to join our growing community.

I have to second @Andrew Chang's thoughts about MDs in development. I think healthcare is so complex, that if you don't have us involved (at least for the front-end), then the end result is always going to be something we don't want to work with.

John Manning (Apr 21 2021 at 21:08):

Some dude here. Happy to chime in. I gave a bunch of resources on my FHIR Connectathon presentation (https://bit.ly/fhir-fli-slides), of which slides 7-8 show the suggestions I like to give on how to get started. Bare minimum, I'd consider watching this 4 min video to get a sense of the power of Flutter, and this 90 sec video to get a sense of what we're doing. Happy to chat more of course. Many of our education and videos focus on the beginner to intermediate developer level

Andrew Chang (Apr 22 2021 at 02:13):

John Manning said: