Comment by webjprgm | Hacker News Reader

Comment by webjprgm | Hacker News Reader

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.

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.

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...

FHIR is gross and overdesigned, like everything else in this moribund industry.

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/ .

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 ).

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 . 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.

So, specifying dateTimes (as defined here: 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.

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)

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.

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.

Happy to hear specific issues! 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.

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.

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.

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.

Reply on news.ycombinator.com