|
|
|
|
|
|
by nradov
3069 days ago
|
|
|
That's inherent in the problem domain. The FHIR data model is distinct from the V3 RIM but clearly influenced by it. Health care has a high degree of irreducible complexity. If we oversimplify the model then it won't support important use cases and implementers will be forced to use proprietary extensions. As a practical matter we can't rely on low-level standards to achieve real interoperability. Since there is often more than one way to model the same clinical information we also need high-level implementation guides with comprehensive examples to show everyone exactly what to do, along with automated conformance testing tools. |
|
|
"What date did this event occur?", can be assertedDate or effectiveDateTime or performedDateTime or any number of things based on resources.
In the old versions it was even hard to know "What's the patient ID associated with this resource?", sometimes it was "patient" sometimes it was "subject". This has gotten better in STU3, and improvements have also been made to the way practitioners are identified as well.
I think there's a ton of irreducible complexity, but there are also common themes and common parts of medicine that should form the foundation of the API. It seems that instead of thinking, "What are the real commonalities here? Lets make them flexible enough to handle 90% of cases, but with a standard interface for extension." HL7 started from a current cumbersome standard and shoehorned it in.
I really am optimistic though, it's getting better all the time and FHIR is actually remarkably extensible to handle corner cases. I really hope it becomes the standard moving forward, especially as it smooths out the rough edges.