PIIM

A PIIM is a Platform Independent Implementation Model, a kind of PIM.

Need for a PIIM

• Rene: Looking at the experiences of v3 developers, who all say that MDA is necessary for proper v3 implementation, I'd personally suggest that it's probably time that HL7 created (and publishes) an UML (enriched with OCL) specification of its static model artefacts as well as the data types. Having UML allows implementers to use tons of standard tools; and it helps them to avoid the schema-based implementation pitfall. (Note: this doesn't mean that MIF goes away, but just that there's an official transform with published UML files).
• Grahame: Lloyd and I have spoken about producing a PIM type model like Rene proposes (it is UML - with as few stereotypes and property strings as we can get away with. Vanilla UML as much as possible..) We know what's involved, it just needs tooling done - but it won't happen unless people start asking for it - and there's also a resources stion I don't think it can entirely be done for r1, but it can entirely be done for r2 If we want MDA, then we should not do serializationss at all, and just do PIIMs.
• Lloyd: My understanding (from past conversations) is that a PIIM is just an RMIM with the magic exposed. So InfrastructureRoot stuff gets exposed, mandatory gets turned into the nullFlavor being exposed or not permitted, binding to concrete datatypes, dropping CMETs and replacing with direct model references. Whole thing expressed as UML. If the requirements were written up, it should be doable as a simple transform. Grahame: There's devils in the details, particularly in the graphics side of things and UML consistency.

• John Koisch: getting to a solution is vital - working software trumps everything else. This is why "just" providing a PIIM is insufficient. But ignoring some of the design decisions that were made in the process to date is silly - babies and bathwater. Grahame has the right of it - complexity does not go away in the real world, no matter how many frameworks you put in place. What is needed is a way to contextualize the simplest possible solutions within the complex reality that is healthcare. Developers need to be able to ignore the non-essential parts of a solution stack without endangering the scalability and efficacy of the solution. A dumb-simple implementable model needs to be traceable to mammoth monstrosity that expresses the complexity.

• William Goossen: Conceptual materials expressed in any format can currently be formalized into logical UML models as e.g. DAM (whole domain, actors, process, interactions, datamodel course), or DCM (data model max fine grained, OCL, XMI exports). This is platform, implementation and technology independent. Having HL7 UML PIIM would allow an almost seamless stream from logical models to HL7 specific logical models and downstream to serialized materials. Most important advantage seems that the mapping from logical model components (class, attributes etc) to HL7 UML components (full exposed) and adding the missing technology specific requirements (e.g. patient, providers, moodcode etc.) can be handled consistently and traceable, instead of having to redo from UML to RIM speak tools with all manual errors that normally go into it.

Discussion on serialization

• Grahame: I think part of the idea of a PIIM is that it puts us out of the serialisation business. Here's the model, you need to agree on serialisation out of some box somewhere. Only for a few things - CDA type things - does HL7 have an opinion.
• Lloyd: need to provide at least one workable serialization implementers can use as a default or a recommendation of a standardized third-party one..I'm not saying we prevent the use of others. If the model is fully defined, and we have clear rules about what needs to be expressed in a wire form to be "safe", no reason we can't open it up to anyone who wants to play, though I'd encourage limiting the number of "officially endorsed" versions to a small number to minimize needless profusion and implementer grief.
• Grahame: Well, see, there you go. the tension between allowing anything or just picking one of a few is exactly the tension between vendors and programs I talk about here: [1] (bottom half)
• Alexander: the absolute worst thing HL7 could do is leave the serialization business and leave that to undefined third parties. The current pace at which ITS-es pop up is absolutely a killer for interoperability, and confuses just about anyone I have spoken to, except for a happy few. Without serialization HL7 is not a solution anymore, but just a nice thought with a long time to market, and even steeper investments in knowledge to get it to work for you. Example: Green CDA was marketed through all channels I read as "something better than HL7". HL7 has to stop endorsing new ITS-es, and stick with exactly one.
• Lloyd: If we're in an environment where implementations are going to have to custom code because they're going to screw up essential elements like null flavors, vocabulary bindings, etc. if they try using off-the-shelf serializers, then there's no reason for HL7 to not develop a custom serializer and ensuring consistency. If there are existing technologies that can take more "complete" artifact (e.g PIIM) and perform serialization/deserialization or code generation and actually get stuff right, then the question becomes is there a market need for implementers to go off and use different ones based on implementation decisions. Certainly there are areas where HL7 definitely shouldn't "standardize". E.g. If we were to say "HL7 must only be implemented using C#", the implementer community would rightly tell us we'd severely overstepped our bounds. In part, that's because HL7 interoperability is not dependent on programming language. When v3 atarted, there were no standard serializations for object models. That's probably one of the reasons we never bothered to implement a PIIM. Now that there are, we need to decide whether serialization mechanism is one of the areas that HL7 allows a multiplicity of, just like we do (in theory) with ITSs.
• Alexander: Ok, if HL7 were to be expressed in an industry recognized, standardized models, and if those models have one (preferably not more) industry recognized standardized way to serialize instances, then yes I would be ok with HL7 not doing this by itself. To date that is not the case, and it would be wrong for HL7 to start migrating to that scenario by leaving the serialization business first. While migrating to any new scenario, HL7 should make sure it keeps delivering solutions that guarantee interoperability (up to a certain level). @Lloyd: I'm not going to contradict your argument about certain areas that HL7 should not standardize, as I think we all agree there.
• Grahame: Out of the serialisation business means that we don't define the serialisation. It might also mean that we don't choose just one either. But more likely, it means that we we choose a particular one for some circumstances, while allowing implementers to choose when that's appropriate