4 ms·

Your homepage there has a heavy focus on health records. Have you considered building upon the FHIR standard?

by doughj3 10y ago

JusticeJuice 10y ago
Yes, thats the main focus of the project. One of my critiques of healthcare systems is they do wayyy to much. Eg a practice management system (pms), handles appointments, records, invoicing, staff management, inventory, decision support - so much stuff. I'm instead focusing on just health records - and the interfaces medical professionals use to work with them. I've had a good look at FHIR and many other standards, but FHIR is built for an interoperability model - eg, your record is sent back and forth between your gp, hospital, specialist, labs, etc. I'm instead focusing on a central access model - so all of the parties interested in your record are all accessing one central point, so I'm doing something a bit different, it almost looks like NPM. That being said, I'm all for any standard becoming the industry standard - I don't care what it is, anything is better than nothing. So I wish FHIR the best of luck :) http://standardhealthrecord.org/ http://standardhealthrecord.org/ is also a standard I really like
- numbsafari 10y ago
  Have you considered, in your model, how your system would work if a customer wanted to integrate with, as an example, a machine learning platform that attempts to predict the likelihood of a patient's readmission given their current status?
  - JusticeJuice 10y ago
    Yeah, I have. A health record is a collaboration - unlike a medical record, which just shows a slice of your health from the perspective of a single institution, a health record aims to show as many facets as possible. An EHR system should be agnostic about who access the record, and what they use it for - obviously gps, specialists, hosptitals, labs, the patient should all have access - but what about, as your said, software? The ideal system would be,patient visits your system, goes through an OAuth flow, and your system has api access. The tricky part is format. Its really hard to define a format which fits the entire world's use case. If you consider, what is healthcare information - you realize it's any data relevant to the patients health. So how can you even start to define that? My compromise is a system where formats are promoted to become popular, regionally, and condition specific. So if you're building a machine learning readmission software, you can target a specific market - say British Primary care, or a specific condition, say diabetes. You can expand out to other markets by writing transformers to translate from one regional format to another.
    - phkahler 10y ago
      It would be best to have a model where the patient "owns" their own records.
    - numbsafari 10y ago
      So, if I want to run an daily analysis of every record in your system, does that processing happen on your system, or do you somehow replicate the data to me? I guess my point is... it's likely that you may want a "single source of truth" for the data, but farm out copies for other applications. And once you do that, you probably want some kind of "replication protocol" that sends updates, rather than making a full copy of the data every day. And once you've done that, aren't you right back where we are today?
      - JusticeJuice 10y ago
        It's a self hosted system - so you as an institution have a copy of all of your patients records on your own servers, which you control. So analyse away. What it provides is a way to replicate some or all of the record to other health institutions. Say, you share the patient's medication list with the hospital - they also keep a copy. When you prescribe a new medicine, the hospital's copy also gets updated. And yes, arguably this is just another version of interoperability. However, if you want to share healthcare information, in a way which allows institutions to have freedom, it's unavoidable. The concept of interoperability isn't bad, just the implementation is. The alternative is all patients records are kept, and accessed from the same place. However, this is very tricky. Many governments have tried to make national health record storage systems, which had immense budgets, and didn't really work out. Often with systems controlled by one party, it's hard to work on ideas which don't fit their goals. Say if you have this great idea for a new format to manage diabetes - that wont fit into their standard format, and you'll have to work outside of their system. Not to mention the control over the population this organisation would have. Patient owned and controled systems are often suggested, and have been built, but I've never seen one work. Patients expect their doctor to manage their record - and they pay for them. It would be a huge challenge to get every patient to pay their yearly 'health record server fees'. On top of that, heath records also belong to the doctors - legally in NZ they have to keep a copy of your record for 10 years since your last visit. For their own liability they need access. In my mind only two models can really work - Goverment run systems which are run better than current systems - A better take on the interoperability model
- fredsmith42 10y ago
  Most if not all health care systems are implementing FHIR as a layer over HL7. Most of those systems don't have people really conversant with web technologies. Interoperability is, I think, a mirage built on top of already overworked integration staffs.
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

Your homepage there has a heavy focus on health records. Have you considered building upon the FHIR standard?

by doughj3 10y ago

Your homepage there has a heavy focus on health records. Have you considered building upon the FHIR standard?

Yes, thats the main focus of the project. One of my critiques of healthcare systems is they do wayyy to much. Eg a practice management system (pms), handles appointments, records, invoicing, staff management, inventory, decision support - so much stuff. I'm instead focusing on just health records - and the interfaces medical professionals use to work with them. I've had a good look at FHIR and many other standards, but FHIR is built for an interoperability model - eg, your record is sent back and forth between your gp, hospital, specialist, labs, etc. I'm instead focusing on a central access model - so all of the parties interested in your record are all accessing one central point, so I'm doing something a bit different, it almost looks like NPM. That being said, I'm all for any standard becoming the industry standard - I don't care what it is, anything is better than nothing. So I wish FHIR the best of luck :) http://standardhealthrecord.org/ http://standardhealthrecord.org/ is also a standard I really like

numbsafari 10y ago
Have you considered, in your model, how your system would work if a customer wanted to integrate with, as an example, a machine learning platform that attempts to predict the likelihood of a patient's readmission given their current status?
- JusticeJuice 10y ago
  Yeah, I have. A health record is a collaboration - unlike a medical record, which just shows a slice of your health from the perspective of a single institution, a health record aims to show as many facets as possible. An EHR system should be agnostic about who access the record, and what they use it for - obviously gps, specialists, hosptitals, labs, the patient should all have access - but what about, as your said, software? The ideal system would be,patient visits your system, goes through an OAuth flow, and your system has api access. The tricky part is format. Its really hard to define a format which fits the entire world's use case. If you consider, what is healthcare information - you realize it's any data relevant to the patients health. So how can you even start to define that? My compromise is a system where formats are promoted to become popular, regionally, and condition specific. So if you're building a machine learning readmission software, you can target a specific market - say British Primary care, or a specific condition, say diabetes. You can expand out to other markets by writing transformers to translate from one regional format to another.
  - phkahler 10y ago
    It would be best to have a model where the patient "owns" their own records.
  - numbsafari 10y ago
    So, if I want to run an daily analysis of every record in your system, does that processing happen on your system, or do you somehow replicate the data to me? I guess my point is... it's likely that you may want a "single source of truth" for the data, but farm out copies for other applications. And once you do that, you probably want some kind of "replication protocol" that sends updates, rather than making a full copy of the data every day. And once you've done that, aren't you right back where we are today?
    - JusticeJuice 10y ago
      It's a self hosted system - so you as an institution have a copy of all of your patients records on your own servers, which you control. So analyse away. What it provides is a way to replicate some or all of the record to other health institutions. Say, you share the patient's medication list with the hospital - they also keep a copy. When you prescribe a new medicine, the hospital's copy also gets updated. And yes, arguably this is just another version of interoperability. However, if you want to share healthcare information, in a way which allows institutions to have freedom, it's unavoidable. The concept of interoperability isn't bad, just the implementation is. The alternative is all patients records are kept, and accessed from the same place. However, this is very tricky. Many governments have tried to make national health record storage systems, which had immense budgets, and didn't really work out. Often with systems controlled by one party, it's hard to work on ideas which don't fit their goals. Say if you have this great idea for a new format to manage diabetes - that wont fit into their standard format, and you'll have to work outside of their system. Not to mention the control over the population this organisation would have. Patient owned and controled systems are often suggested, and have been built, but I've never seen one work. Patients expect their doctor to manage their record - and they pay for them. It would be a huge challenge to get every patient to pay their yearly 'health record server fees'. On top of that, heath records also belong to the doctors - legally in NZ they have to keep a copy of your record for 10 years since your last visit. For their own liability they need access. In my mind only two models can really work - Goverment run systems which are run better than current systems - A better take on the interoperability model
fredsmith42 10y ago
Most if not all health care systems are implementing FHIR as a layer over HL7. Most of those systems don't have people really conversant with web technologies. Interoperability is, I think, a mirage built on top of already overworked integration staffs.

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