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/ful...
Happy to help anyone learn more about the spec @medhacker
[1] http://www.annemergmed.com/article/S0196-0644(15)00226-7/ful...
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 ). 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 ) 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 ). 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 ).
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 . 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-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.
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.
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)
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.
I can see it being inconvenient for import into a better designed system. You'd have to make an assumption about time zone.
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.
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.
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.