

New FHIR Documentation - ryanSrich
https://fhir.catalyze.io/

======
angersock
FHIR is a bad answer to a stupid situation.

The fact that it supports extensions and embedded resources is a bad idea.
Some of the later stuff is okay, like the layout of patient objects.

Honestly, a big part of the problem is that nobody seems to be pushing back
and saying "Folks, we've made all of this too damned complicated...let's just
identify useful subsets and make that work."

Also, good luck having any meaningful impact on the discussions if you're not
with one of the vendors or can spare the time for bureaucratic bullshit.

EDIT:

A further note on the patient stuff--it looks reasonable if you look at this
thing's "Show the result of `GET /patients/<whatever>`". However, the actual
spec ( [http://www.hl7.org/implement/standards/fhir/patient-
definiti...](http://www.hl7.org/implement/standards/fhir/patient-
definitions.html) ) kinda hints at a massive headache.

~~~
mthmohan
Author of that doc here. I cannot agree with you more. I have tried to be a
bit more polite about that point of view. It's is complicated and very
unnecessarily so at times. Lots of gaps as well. The main hope I have is that
there are a lot of players involved in this (such as BIDMC) who could drive
some change.

Thanks for the comment

~~~
angersock
Being polite is in good part what has allowed the situation to degrade as far
as it has in our industry. Bozos and yesmen. I understand why you might be
more diplomatic though! :)

We're working on an open waveform format to replace WCM, for example, and the
amount of silliness there staggers the mind.

Who are you aware of that's actually interested on working on a slimmer,
easier-to-use system for this stuff?

