Imagine having to only use one particular tool to run your life consistently, while this may sound bizarre it almost shackles the healthcare industry. Granted we can get into talking about scale and needs however in this post I would like to talk more about how we can, and should be, utilizing best of breed software, vendors and technology for everything we do in healthcare.
Medical record data is full of hidden gotchas that a data professional can stumble into. My favorite example is Blood Pressure.
What Is Blood Pressure?
Blood Pressure is a measurement of force exerted by the heart on blood in order to move it through the body. It is a key indicator of heart health, made up of two measurements: Systolic Pressure (the pressure inside your blood vessels when your heart beats) and Diastolic Pressure (the pressure inside your blood vessels when your heart rests between beats). In its informative form, Blood Pressure is displayed to clinicians like this:
One of the biggest challenges in healthcare, actually with almost any business, is working with and relating to others; which we happily call leadership.
Sharing records is not anything new in healthcare, albeit most are still faxed when you go to one doctor vs another or electronically sent using CCDA or if you are fortunate to have an integrated system they may be passed through an internal viewer.
When systems work to setup their data sharing, or an ACO or CIN is getting started one of the most common approaches is they first reach out to all their provider groups to sign a data sharing agreement and then they begin to collect their data and in return at some point in the future they will share that.
It's time to change that approach.
True or false? There are no two similar snow flakes. (keep reading to find the answer)
Healthcare is a rewarding field to work in, our work directly effects lives and families. It is very easy to trace your work in healthcare and see how it improves others lives.
However when it comes to technology we often try to think that our own solutions are unique and can't be addressed by any other means. While it is true we have very unique circumstances in healthcare from how we use data to how we input it to the uniqueness of each client and system, the reality is we can learn from other industries to solve 90% of our own technology shortcomings, the last 10% is what make healthcare rewarding.
This is the first installment in a series exploring publishing npm packages. The goal is to walk through publishing everything from a simple, dozen-or-so lined node module to a relatively complicated react component library with typescript & flow definition files and pretty import paths.
In healthcare the current hottest trend we see is analytics software that seems to have the promise to do it all. Often times Integration Engines, HIEs and Population Health Management is also thrown into the mix to confuse things even more. Regardless of which you are looking at, we are going to call these "Analytics" software.
Don't get us wrong we are not against any analytics software, however we are against the case for yet another silo to be created, but this can be managed!
In healthcare you will often hear, or see in the news, talks about care gaps. Care gaps is used to describe when a link in the chain along the journey is not connected. Think of care gaps as a way to address a particular path/journey/experience in the same manner every time.
In healthcare it seems we are always talking about the latest type of connection you can use HL7, FHIR, ADT and the list goes on; what is even more comical is it changes based on who you are talking to Provider? Payer? Patient?
It feels like the fix for integration has been to create a new type of integration standard. However it is not all about these times of connectors or integrations, we can actually reduce down all this into 3 main areas to focus on.
When I talk to CEOs and CIOs often the first question I get is what are APIs and followed almost immediately by why do I need them? Perhaps, as I have come to learn, the root of the question is do I really need it? I mean after all we do have HL7 so why APIs and how are they different.