5 ms·

Can you be specific? I'm a skeptic but just now learning about it.

by gmarx 11y ago

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
  So, I could actually show you the emails where I helped move JSON from a MAY implement (with XML as a SHALL), to it being a proper first class member of the spec. The FHIR core team was and continues to be interested in feedback from experienced integrators. I read your comments here occasionally; you're smart, participate! You use the phrase 'lingua franca' which provides and interesting analogy - it was implemented globally by a group of imperialists who controlled the trade transshipment points of a big chunk of the world by force of arms; is there a corollary in health care? Actors on the web that have a profit motive to play together have adopted a set of norms (REST, JSON) to manage tasks that are usually trivial compared to medical knowledge representation. We still can't get an iCal right, for goodness' sake. Everyone else is buttoned up, and FB and GOOG don't exactly share network data with each other. Regarding point four: if it get's specific to times, then you do have to indicate time zone, just ate the dateTime level: "If hours and minutes are specified, a time zone SHALL be populated." (https://www.hl7.org/fhir/datatypes.html#dateTime https://www.hl7.org/fhir/datatypes.html#dateTime)
  - angersock 11y ago
    Thanks for getting JSON into a SHALL. :) It's not a timezone on point 4, as explained elsewhere that's the offset (if I'm reading the spec correctly here). As a minor history point...JSON was "discovered" by Crockford and given away as a spec, to everyone, to make life easier. REST is a (still hotly debated) style for designed HTTP API endpoints. :) The thing about the medical knowledge representations is that every single bloody thing that might be useful to implementors or folks looking to improve the field (from the outside, because inside medicine there are significant structural and political issues preventing meaningful change) is locked behind a goddamn paywall, taxed and kept from view lest it ever actually get out there and be useful. How much does it cost to get a copy of, for example, the standards for displaying ECG signals? Do you know where you'd purchase them offhand? How about that SNOMED? Medicine is basically the poster child for what happens when a community is allowed to horde knowledge and IP and then self-police to ensure that you can't interact with them without paying for that stuff.
- gmarx 11y ago
  Including XML and RDF doesn't bother me. A lot of people greatly prefer JSON over XML. I don't get exorcised either way. The final two look like problems. I would guess the penultimate one is because most medical systems ignore time zone so you just assume it happened in the time zone of the system of origin. It probable doesn't matter often in practice. If two different patients had a lab test done on opposite sides of the world would that knowledge ever be important? On the other hand, time is important within a patient data set. This might be a problem if a patient radically changed time zones within the course of a day. I can see it being inconvenient for import into a better designed system. You'd have to make an assumption about time zone.

Can you be specific? I'm a skeptic but just now learning about it.

by gmarx 11y ago

Can you be specific? I'm a skeptic but just now learning about it.

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
So, I could actually show you the emails where I helped move JSON from a MAY implement (with XML as a SHALL), to it being a proper first class member of the spec. The FHIR core team was and continues to be interested in feedback from experienced integrators. I read your comments here occasionally; you're smart, participate! You use the phrase 'lingua franca' which provides and interesting analogy - it was implemented globally by a group of imperialists who controlled the trade transshipment points of a big chunk of the world by force of arms; is there a corollary in health care? Actors on the web that have a profit motive to play together have adopted a set of norms (REST, JSON) to manage tasks that are usually trivial compared to medical knowledge representation. We still can't get an iCal right, for goodness' sake. Everyone else is buttoned up, and FB and GOOG don't exactly share network data with each other. Regarding point four: if it get's specific to times, then you do have to indicate time zone, just ate the dateTime level: "If hours and minutes are specified, a time zone SHALL be populated." (https://www.hl7.org/fhir/datatypes.html#dateTime https://www.hl7.org/fhir/datatypes.html#dateTime)
- angersock 11y ago
  Thanks for getting JSON into a SHALL. :) It's not a timezone on point 4, as explained elsewhere that's the offset (if I'm reading the spec correctly here). As a minor history point...JSON was "discovered" by Crockford and given away as a spec, to everyone, to make life easier. REST is a (still hotly debated) style for designed HTTP API endpoints. :) The thing about the medical knowledge representations is that every single bloody thing that might be useful to implementors or folks looking to improve the field (from the outside, because inside medicine there are significant structural and political issues preventing meaningful change) is locked behind a goddamn paywall, taxed and kept from view lest it ever actually get out there and be useful. How much does it cost to get a copy of, for example, the standards for displaying ECG signals? Do you know where you'd purchase them offhand? How about that SNOMED? Medicine is basically the poster child for what happens when a community is allowed to horde knowledge and IP and then self-police to ensure that you can't interact with them without paying for that stuff.
gmarx 11y ago
Including XML and RDF doesn't bother me. A lot of people greatly prefer JSON over XML. I don't get exorcised either way. The final two look like problems. I would guess the penultimate one is because most medical systems ignore time zone so you just assume it happened in the time zone of the system of origin. It probable doesn't matter often in practice. If two different patients had a lab test done on opposite sides of the world would that knowledge ever be important? On the other hand, time is important within a patient data set. This might be a problem if a patient radically changed time zones within the course of a day. I can see it being inconvenient for import into a better designed system. You'd have to make an assumption about time zone.