5 ms·

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 s

by 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.
      - angersock 11y ago
        So, specifying dateTimes (as defined here: https://www.hl7.org/fhir/datatypes.html#dateTime https://www.hl7.org/fhir/datatypes.html#dateTime) is not sufficient. Remember, it isn't including the timezone (no code or anything), it's including the offset. The difference there is the usual conflation of time and timezone and location...basically, if you don't have the actual physical and political location, the offset is of only academic interest and you might as well just display UTC. On 3, the complaint was specifically caused by this passage: "However, this is frequently not possible due to legacy data and/or clerical practices when recording contact details. For this reason, phone, fax, page and email addresses are not handled as formal URLs. For other kinds of contacts, the system is "other" and the value SHOULD be a URL so that its use can be determined automatically." Addresses (post, in your case) are arguably best handled as dumb strings, of type "garbage_human_address". The problem I have is with the explicit admission of "well, support the legacy", when everyone knows that the legacy stuff needs to go. We've been killing ourselves by compromising and allowing the mistakes of the past corrupt the systems of the future in healthcare. As for #2: if there is ever any question about the representation of numbers, especially in JSON, you store them as strings. Twitter ran into this with ids, other people have too, and it's just generally icky. If the Javascript/JSON representation of numbers is being used (and it shouldn't, because the numeric types in JS are kinda broken), then there shouldn't be the restriction on exponential notation.
- lbhnact 11y ago
  Happy to hear specific issues! https://chats.fhir.me/feeds/skype/implementers.html https://chats.fhir.me/feeds/skype/implementers.html - best place to participate if you want to help. Even at v1.0, many people are open to changes that reflect the needs of strong cases. There are compromises in any API, and FHIR does a decent job of making common needs things simple, the alterative would be some RIM or graph based model that you'd have to get graduate degree in before you could say 'just GET me a Potassium result dammit'. Please reach out if you see ways the spec could improve.
- nradov 11y ago
  Instead of complaining, feel free to propose a better alternative. The HL7 standards development process is very open. However usually the complaints about health IT complexity come from people with a lack of domain knowledge. The industry is irreducibly complex. Attempts to drastically simplify the IT systems and standards are doomed to failure since they lose the ability to cope with many common real world situations.
  - angersock 11y ago
    The industry's irreducible complexity is killing people every day, and bankrupting the survivors. The fact of the matter is that the gatekeepers blocking improvement (which really only is attainable through simplification and standardization) are going to keep doing so until they die or are payed off. We've spent 30 years building up a morass of incompatible and tailored systems and then training all the administrators that this is somehow normal and acceptable.
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.

by lbhnact 11y ago

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.
    - angersock 11y ago
      So, specifying dateTimes (as defined here: https://www.hl7.org/fhir/datatypes.html#dateTime https://www.hl7.org/fhir/datatypes.html#dateTime) is not sufficient. Remember, it isn't including the timezone (no code or anything), it's including the offset. The difference there is the usual conflation of time and timezone and location...basically, if you don't have the actual physical and political location, the offset is of only academic interest and you might as well just display UTC. On 3, the complaint was specifically caused by this passage: "However, this is frequently not possible due to legacy data and/or clerical practices when recording contact details. For this reason, phone, fax, page and email addresses are not handled as formal URLs. For other kinds of contacts, the system is "other" and the value SHOULD be a URL so that its use can be determined automatically." Addresses (post, in your case) are arguably best handled as dumb strings, of type "garbage_human_address". The problem I have is with the explicit admission of "well, support the legacy", when everyone knows that the legacy stuff needs to go. We've been killing ourselves by compromising and allowing the mistakes of the past corrupt the systems of the future in healthcare. As for #2: if there is ever any question about the representation of numbers, especially in JSON, you store them as strings. Twitter ran into this with ids, other people have too, and it's just generally icky. If the Javascript/JSON representation of numbers is being used (and it shouldn't, because the numeric types in JS are kinda broken), then there shouldn't be the restriction on exponential notation.
lbhnact 11y ago
Happy to hear specific issues! https://chats.fhir.me/feeds/skype/implementers.html https://chats.fhir.me/feeds/skype/implementers.html - best place to participate if you want to help. Even at v1.0, many people are open to changes that reflect the needs of strong cases. There are compromises in any API, and FHIR does a decent job of making common needs things simple, the alterative would be some RIM or graph based model that you'd have to get graduate degree in before you could say 'just GET me a Potassium result dammit'. Please reach out if you see ways the spec could improve.
nradov 11y ago
Instead of complaining, feel free to propose a better alternative. The HL7 standards development process is very open. However usually the complaints about health IT complexity come from people with a lack of domain knowledge. The industry is irreducibly complex. Attempts to drastically simplify the IT systems and standards are doomed to failure since they lose the ability to cope with many common real world situations.
- angersock 11y ago
  The industry's irreducible complexity is killing people every day, and bankrupting the survivors. The fact of the matter is that the gatekeepers blocking improvement (which really only is attainable through simplification and standardization) are going to keep doing so until they die or are payed off. We've spent 30 years building up a morass of incompatible and tailored systems and then training all the administrators that this is somehow normal and acceptable.

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.