6 ms·

No discussion about APIs in health care EMRs would be complete without mentioning HL7's new FHIR protocols: REST-ful web service endpoints for HL7 health data.

No discussion about APIs in health care EMRs would be complete without mentioning HL7's new FHIR protocols: REST-ful web service endpoints for HL7 health data. It makes developing applications with these standards much easier. But that's only one piece. You need business relationships to even connect to the EMR in the first place. I think the problem with breaking into this industry is: (1) Huge incumbents with tons of cash who have shown they will spend a lot of money to smear each other, buy out smaller companies, or just implement the new feature in their own system. (2) Excessive government regulation which makes it hard to play in this area legally and makes everyone afraid to work with you. I had a couple friends pitch me a medical-related startup idea a few years ago and I declined. They didn't last long before some bigger player came and implemented their idea thus stealing their customers. Also, the article mentions reinventing the wheel of integration libraries. Having open APIs will not magically solve all problems. It mentions Kareo and says they are building out their own EHR. THAT is reinventing the wheel. An EHR is mega-huge. It has tons of modules and for the main vendors takes 18 months to 2 years or so to configure it to the satisfaction of all parties. It sounds like the advocated world is to have lots of small "open platform" companies re-invent the wheel by making a new EHR module-by-module but with different startups inter-operating instead of locking each other out. You realize that all the major vendors today started like that? They were all first one module and gradually added more. Why do you think hospitals tend to buy the integrated software to replace myriads of independent legacy systems? If you can't fully understand that and articulate why your "open platform" would be better then you're going to fail.

lbhnact 11y ago
FHIR is probably the best hope that we've got. I am biased of course, but I've bet a few years of my life on it. :) Happy to help anyone learn more about the spec @medhacker [1] http://www.annemergmed.com/article/S0196-0644(15)00226-7/fulltext http://www.annemergmed.com/article/S0196-0644(15)00226-7/ful...
- angersock 11y ago
  FHIR is gross and overdesigned, like everything else in this moribund industry.
  - gmarx 11y ago
    Can you be specific? I'm a skeptic but just now learning about it.
    - angersock 11y ago
      So, link is here for people playing the home game: https://www.hl7.org/fhir/ https://www.hl7.org/fhir/ . First, it specifies 3 different formats: JSON, XML, RDF. It should only pick one, preferably JSON, because that's the lingua-franca of the web. Second, the datatypes are handled oddly ( https://www.hl7.org/fhir/datatypes.html https://www.hl7.org/fhir/datatypes.html ). Numbers, for example are supposed to handle arbitrary precision, but they pick the wrong datatype for it in things like JSON (should arguably be a string, or a properly-formatted Number). Third, things like ContactPoints ( https://www.hl7.org/fhir/datatypes.html#contactpoint https://www.hl7.org/fhir/datatypes.html#contactpoint ) are left too open-ended. You run into things like "Well, this is not structured, some um I guess you should chase a URL to figure out how to deal with it". The point of a standard should be to standardize these fields...leave remediation to the people hired to do implementation and assume it is done correctly. Fourth, time is still not quite handled correctly ( https://www.hl7.org/fhir/datatypes.html#period https://www.hl7.org/fhir/datatypes.html#period ). Period, for example, doesn't say what time zone the contents are in--a simple note "Hey, this should be in UTC" would have sufficed. There are other issues around things like letting users bundle in embeddings of HL7 and other things, basically saying "this data can have arbitrary structure". It's a punt, and leads to things like having to infer (if you can) what a value means from it's "type" or "system" ( https://www.hl7.org/fhir/datatypes.html#codeableconcept https://www.hl7.org/fhir/datatypes.html#codeableconcept ).
      - rickard 11y ago
        I don't quite agree with your complaints. Regarding #2, what do you consider the problem with representing arbitrary precision decimals as numbers? That your javascript json parser converts json numbers to 64-bit floats? I'm not sure that that is really a problem with FHIR - see e.g. https://www.npmjs.com/package/json-bigint https://www.npmjs.com/package/json-bigint . Or is the problem that exponents aren't allowed? About #3, how would you standardise addresses? ISO has been at it for several years and still not produced a standard. See e.g. http://stackoverflow.com/questions/4840928/iso-standard-street-addresses http://stackoverflow.com/questions/4840928/iso-standard-stre... for relevant links. Your fourth complaint is plain invalid. A period consists of two dateTimes, both of which specify time zones. Number one and five I can somewhat sympathise with, though.
- GoodOldNe 11y ago
  EM resident with an interest in EHR design and development here -- this is really cool, I didn't take a close enough look at this in Annals in August but I'm reading about the spec now. Looks promising.
markolschesky 11y ago
I'm totally on board with FHIR. I just don't think we're there yet. I've talked with 3 of the Argonaut sites and real-life, production ready FHIR capabilities are lacking. There aren't many useful provider-facing applications that you can built with just GET requests. Most applications require real-time pushing and pulling of data. As sad as it is, until FHIR as implemented (not theoretically) that way, we'll still be plugging HL7v2 together. I, as an HL7v2 slinger myself, hope that goes away soon.

lbhnact 11y ago

FHIR is probably the best hope that we've got. I am biased of course, but I've bet a few years of my life on it. :) Happy to help anyone learn more about the spec @medhacker [1] http://www.annemergmed.com/article/S0196-0644(15)00226-7/fulltext http://www.annemergmed.com/article/S0196-0644(15)00226-7/ful...

angersock 11y ago
FHIR is gross and overdesigned, like everything else in this moribund industry.
- gmarx 11y ago
  Can you be specific? I'm a skeptic but just now learning about it.
  - angersock 11y ago
    So, link is here for people playing the home game: https://www.hl7.org/fhir/ https://www.hl7.org/fhir/ . First, it specifies 3 different formats: JSON, XML, RDF. It should only pick one, preferably JSON, because that's the lingua-franca of the web. Second, the datatypes are handled oddly ( https://www.hl7.org/fhir/datatypes.html https://www.hl7.org/fhir/datatypes.html ). Numbers, for example are supposed to handle arbitrary precision, but they pick the wrong datatype for it in things like JSON (should arguably be a string, or a properly-formatted Number). Third, things like ContactPoints ( https://www.hl7.org/fhir/datatypes.html#contactpoint https://www.hl7.org/fhir/datatypes.html#contactpoint ) are left too open-ended. You run into things like "Well, this is not structured, some um I guess you should chase a URL to figure out how to deal with it". The point of a standard should be to standardize these fields...leave remediation to the people hired to do implementation and assume it is done correctly. Fourth, time is still not quite handled correctly ( https://www.hl7.org/fhir/datatypes.html#period https://www.hl7.org/fhir/datatypes.html#period ). Period, for example, doesn't say what time zone the contents are in--a simple note "Hey, this should be in UTC" would have sufficed. There are other issues around things like letting users bundle in embeddings of HL7 and other things, basically saying "this data can have arbitrary structure". It's a punt, and leads to things like having to infer (if you can) what a value means from it's "type" or "system" ( https://www.hl7.org/fhir/datatypes.html#codeableconcept https://www.hl7.org/fhir/datatypes.html#codeableconcept ).
    - rickard 11y ago
      I don't quite agree with your complaints. Regarding #2, what do you consider the problem with representing arbitrary precision decimals as numbers? That your javascript json parser converts json numbers to 64-bit floats? I'm not sure that that is really a problem with FHIR - see e.g. https://www.npmjs.com/package/json-bigint https://www.npmjs.com/package/json-bigint . Or is the problem that exponents aren't allowed? About #3, how would you standardise addresses? ISO has been at it for several years and still not produced a standard. See e.g. http://stackoverflow.com/questions/4840928/iso-standard-street-addresses http://stackoverflow.com/questions/4840928/iso-standard-stre... for relevant links. Your fourth complaint is plain invalid. A period consists of two dateTimes, both of which specify time zones. Number one and five I can somewhat sympathise with, though.
GoodOldNe 11y ago
EM resident with an interest in EHR design and development here -- this is really cool, I didn't take a close enough look at this in Annals in August but I'm reading about the spec now. Looks promising.

markolschesky 11y ago

I'm totally on board with FHIR. I just don't think we're there yet. I've talked with 3 of the Argonaut sites and real-life, production ready FHIR capabilities are lacking. There aren't many useful provider-facing applications that you can built with just GET requests. Most applications require real-time pushing and pulling of data. As sad as it is, until FHIR as implemented (not theoretically) that way, we'll still be plugging HL7v2 together. I, as an HL7v2 slinger myself, hope that goes away soon.