5 ms·

Double bonus for this, we've been working with FHIR at Lumiata and it's quite good for certain things. Difficulty is that most EMRs as is work with tabular data

by entee 10y ago

Double bonus for this, we've been working with FHIR at Lumiata and it's quite good for certain things. Difficulty is that most EMRs as is work with tabular databases, and FHIR isn't quite organized that way. It does require some work to translate the tables people usually have into that format. Still a native FHIR EMR would be really cool! [EDIT]: https://www.hl7.org/fhir/ https://www.hl7.org/fhir/ for the interested

JusticeJuice 10y ago
Lumiata looks super interesting. Ps your https is expired? As a company trying to use machine learning to predict healthcare risk, what do you look for in a format to work with? How do you deal with incomplete data / incorrectly formatted data?
- entee 10y ago
  Above all we want a data format that's consistent. The nice thing about FHIR is that it quickly allows us to join up all the data for a single patient, and all the pieces of data we need are always in the same, standards-compliant place. It also does a good job of defining what datatype to expect when you access a part of the patient record (low bar, but yeah, medical data :( ). The bad part about FHIR is that it's so heavily nested and flexible that it can get annoying to extract some of the data. For example, the date that something happened is accessible by a different key or keys based on the type of event that happened. Same with trying to access what doctor was responsible for that event. That's meaningful medically, and one-size-fits-all in these things is hard, but I have to jump through all sorts of hoops to get to it and write lots of "if this then that" code to get the same information. There are also some odd omissions. For example ethnicity isn't super consistently represented. For incomplete data, we deal with very large numbers of patients so some of that washes out in the aggregate as we build models. If the data for a given patient is truly incomplete, we then simply don't use that patient. We do a few other things, but can't go into much detail here ;). Incorrectly formatted data drives me nuts. It's super manual. We pass things through a series of filters and reshaping that helps cut down on the problem, but it sucks. A lot. Not much to do but try to figure out rules for common data entry or format screwups. re. HTTPS, yeah it's screwed up in a couple ways but we're getting it fixed. The public website has nothing to do with how we secure/transfer/handle client data though. If you've got more questions, I'd be happy to email, feel free to reach out at ntilmans@lumiata.com
mdoneill 10y ago
At MedicaSoft, we are building a native FHIR EMR and PHR. See medicasoft.us.

by entee 10y ago

JusticeJuice 10y ago

Lumiata looks super interesting. Ps your https is expired? As a company trying to use machine learning to predict healthcare risk, what do you look for in a format to work with? How do you deal with incomplete data / incorrectly formatted data?

entee 10y ago
Above all we want a data format that's consistent. The nice thing about FHIR is that it quickly allows us to join up all the data for a single patient, and all the pieces of data we need are always in the same, standards-compliant place. It also does a good job of defining what datatype to expect when you access a part of the patient record (low bar, but yeah, medical data :( ). The bad part about FHIR is that it's so heavily nested and flexible that it can get annoying to extract some of the data. For example, the date that something happened is accessible by a different key or keys based on the type of event that happened. Same with trying to access what doctor was responsible for that event. That's meaningful medically, and one-size-fits-all in these things is hard, but I have to jump through all sorts of hoops to get to it and write lots of "if this then that" code to get the same information. There are also some odd omissions. For example ethnicity isn't super consistently represented. For incomplete data, we deal with very large numbers of patients so some of that washes out in the aggregate as we build models. If the data for a given patient is truly incomplete, we then simply don't use that patient. We do a few other things, but can't go into much detail here ;). Incorrectly formatted data drives me nuts. It's super manual. We pass things through a series of filters and reshaping that helps cut down on the problem, but it sucks. A lot. Not much to do but try to figure out rules for common data entry or format screwups. re. HTTPS, yeah it's screwed up in a couple ways but we're getting it fixed. The public website has nothing to do with how we secure/transfer/handle client data though. If you've got more questions, I'd be happy to email, feel free to reach out at ntilmans@lumiata.com

mdoneill 10y ago

At MedicaSoft, we are building a native FHIR EMR and PHR. See medicasoft.us.