Klaus Veil asked me for a comparison of v3 and my alternative proposal (RFH), to help people understand the differences. This is a list of some of the differences.
- the v3 standard is primarily focused on explaining the standard – the process. And with reason – you have to understand the process, from the RIM down, to be able to implement it well. RFH turns that on it’s head: the focus is on explaining what you have to do to conform to the standard. It’s not that there’s actually less to understand – it’s just a different focus on the order in which you encounter things, and why. (My favorite example of the problem the v3 approach causes is the A_SpatialCoordinate cmet. It contains a coherent description of how the parts map to the rim, but the parts are not coherent – and it has passed ballot)
- the v3 process starts from the RIM – the definitions are in the RIM, and you constrain the RIM down by removing optionality and capability to focus on a particular use case, and the instances that are exchanged are RIM instances. In this way, the RIM stands between the business analysis and the implementation model. RFH turns this on it’s head; the implementation is the business analysis model – if there’s a difference between the way business analysts think about the model and the implementation, this difference is explained directly in the implementation model. The implementation model is also secondarily mapped to the RIM – this is required to ensure correctness, but not for interoperability.
- v3 is exploring various forms of simplified xml. The mantra has become, “interoperability is a transform away from the RIM”. RFH embraces this – interoperability is the focus, and the RIM is a transform away. And compromise is fought out in the implementer space, not the definitional space
- n v3, the RIM provides the formalism by defining the base types. Typing is innately an exclusive process, so it doesn’t make sense to also define the concepts against different models/perspectives at the same time. The consequence of this is interminable debates about the ontology of the RIM itself, and the perspectives it enshrines. RFH pushes the RIM into the ontology space, where the definitions are open, not closed. This enables additional definitional perspectives to be introduced where appropriate. It would also allow different parts/patterns/concerns of the RIM to be teased apart (where now they are bound together by being contained in a “class” with all that entails)
- in v3, we were forced to model the universe in order to avoid subsequent breaking changes. RFH doesn’t know how to solve this problem, but can leverage the fact that so much of it has already been done. Without this preexisting work, RFH would have a problem….
- in v3, the definitions are “abstract” so that they can be technology independent. This is wonderful in theory, but requires custom tooling to map between the models and the reality (especially in conformance) – and hardly anyone actually understands this in the data types, let alone elsewhere. How painful this has been… RFH is focused on XML first – the concrete model that is exchanged. Other definitional forms are secondary. And the exact form is based closely on a recognized best of breed model (highrise API)
- in v3, there are multiple overlapping static models, some of which are sort of incompatible from some perspectives. These overlapping models represent a failure of governance – the cat slipped out of the bag before we understood what was at stake, and we never got on top of it. It’s a major issue for CDA R3, for instance. RFH can’t solve this – instead, it elevates this problem to a central concern by insisting that resources are modular and separate, and we have to govern it from the start.
- in v3, we have still not figured out a workable behavioral model. RFH starts with a restful infrastructure – this meets many requirements out of the box. Where it doesn’t, additional service models can be built on top by either HL7 or other adopters as desired, by reusing the resources. RFH defines an aggregation framework for resources to enable this, and this allows documents such as CDA to be natural outcomes of the methodology.
- V3 requires custom tooling – both to produce the specification, and to adopt the specification. RFH still requires tooling to manage the definitional space, and ensure it is coherent, though more of this tooling arises logically from existing ontology toolkits. RFH doesn’t require custom tooling to adopt the specification, though the definitions are there to be leveraged, and that would require tooling.
- v3 treats extensions as entirely foreign content. RFH, on the other hand, makes extensions part of the base content and insists that they be related to the existing definitional content. Since most extensions are based on content properly defined elsewhere, this is more natural and palatable to adopters
- by pinning implementor concerns down, and being open definitionally (rather than the converse as in v3), RFH should offer many disconnected potential members of the community to re-engage.
These are the differences I had in my head as I set out to write RFH.
Not all of these differences will be to everyone’s liking. In particular, there’s no necessity for all the parts of the wire format to map to the RIM – and the resources I’ve already put in RFH don’t – they explicitly represent identification and management concerns that the RIM has never engaged with. So it may be that RFH can’t interoperate with v3 across a gateway.
Also, not all these differences I had in mind are properly represented in RFH – or it may be that they even not properly achieved. RFH isn’t offered up as a final specification, ready to ballot. It’s an idea, an example of what could be achieved if we approached the standards process from this different direction, and maybe it’s also a usable basis for further work.