Friday, August 27, 2010

NIEM - making lemonade out of lemons

Yesterday I learned yet more about NIEM, attending the same session that Keith blogged about. He has some good references worth looking at to get some background. It is clear that NIEM is here to stay. Good, Bad, or Indifferent. So, lets figure out the best way to use this tool.

The NIEM process as visualized by ONC
Overall I think the NIEM process will be a good thing. It is a high level model for dealing with the issues we have been looking at for years. It includes steps that HITSP never got to (although I think this was more a funding problem than anything).
            *** So, will funding be provided to make the WHOLE process work? If it is going to be underfunded or cut apart; then it is not going to be very useful.

The NIEM process is actually very similar to the IHE process.
Except that IHE doesn’t require a 'reference model'. Rather they expect real products to show up at Connectathon, and until three independent products show interoperability at Connectathon then the specification can’t progress. The Reference Implementation model drives ‘academic’ proof, which is not always a good indicator of reality. I have seen how OASIS members abuse this. IHE is a partnership of those that have a problem and would like a solution, and those that could solve the problem if they were given assurances that the solution would be universal and desired. This is critical to why IHE continues to be successful. Yes sometimes what was thought to be desirable at one point is not later on.

            *** The ‘reference model’ is a fine thing, if it happens. But a reference model does not prove the spec will work in real-world situations.
            *** I would like to add the IHE product centric proof step into the NIEM process.

Re-use, don’t Re-invent; I think I heard this in the latest meetings on NIEM. But it needs to be emphasized as important. Most importantly it needs to be communicated that Re-Use is allowed and encouraged. I think NIEM can be very useful at the high level, it needs to be kept very thin. Similar to the overall approach in HITSP, only better (because we have learned).


           *** The biggest risk to success is that NIEM offers consultants unending work.
            *** The NIEM documentation tools are impressive and if they work as advertized the answer to world hunger.

Legacy. Healthcare is not a new, green field. Therefore part of the analysis must include this legacy. The analysis does not need to choose the legacy method, but it must consider the impact. This seems to be totally missing in the NIEM process. Further the focus of NIEM on producing XML and web services will be unproductive in some use-cases (it will be fine in others).

            *** How is the impact on existing investment included in the NIEM process

            *** When there is no single solution, how can NIEM indicate that there are 2 solutions acceptable?

            *** When the solution is not XML or web services, we need a light weight way to document this.

SOA. The process we saw is very heavy on SOA, and the use of SOA terms. This is not a bad thing. The concern is that some will take this as a directive that everything must be reformulated and relabeled using SOA modeling and SOA terms. IHE wrote a white paper that tried to show that there is synergy between the new SOA modeling and terminology; and the IHE modeling and terminology. Unfortunately this renaming exercise wasted lots of valuable time in HITSP and resulted in multiple layers of documentation with no value-add.  Religious wars are unproductive.
            *** We need a more light weight method of handling this.

International. This is not as big of a concern to providers, although they do benefit without knowing. But it is very critical to big vendors that don’t want to have to do things two ways. I suspect the attitude expressed by Doug Fridsma at the NHIN-Direct meeting, that of re-use where standards exist and fit the need, will take care of this issue. But it is still a force to consider. Often times it looks like inventing something special for USA is the right thing to do, it should be resisted. This is not limited to healthcare either, there are plenty of good international security standards to re-use rather than invent something special for USA. Overall I have not come up against a problem being internationally friendly.

            *** Be aware of and guided by experience in the international community

Coordination. ONC needs to Coordinate all of these National initiatives. Hopefully they allow the 10 contracts to coordinate directly rather than force all communications through ONC. I am hopeful that this will happen.

            *** Enable coordination, don’t become a bottle neck

I welcome NIEM, and want to help it succeed by focusing it and keeping it lean. NIEM should be leveraged to add value and clarity; not duplicate what others do and have done. Where a gap is found, NIEM can be leveraged to best describe the gap and determine the best SDO/PDO to fill the gap. Reuse, not Reinvent.


  1. John, do you think that 10 independent efforts can really coordinate directly? (Draw the lines between 10 boxes to see how many communication paths there would have to be)? I think that the "ConOps" that was referred to by John Halamka and Doug Fridsma is supposed to address that. I agree that ONC shouldn't be a bottleneck, but it does seem that "coordination" is ONC's last name, so why wouldn't we expect them to drive the coordination among these contracts?

  2. David, I would love to believe that ONC could actually "Coordinate" these "National" initiatives from their "Office". But history is not kind. They have proven that they are a bad coordinator and at best a bottle neck. So, I am simply asking that they ALLOW the projects to communicate. This has NOT been allowed in the past.