Talk:MnM SWOT
Good start, but there are some other things I might point out on the "weakness" side (since I am in a grouchy mood).
As someone who "gets" modeling, I still find working with the existing tools, even after taking Woody's course (maybe I just need to repeat it) challenging. We need tools which let us start with a base model (specifically the Clinical Statement Pattern) and constrain. This will greatly ease the burden and backlog "in the trenches". MDHT will be a great addition, particularly when it is fully interfaced with the SMD.
We will always need to train people beyond the intro courses on both the modeling process, and the tools. While the cause for the limited number of very basic tool-focused course was cited as "lack of bandwidth" this may be because there are not enough people with the expertise in the HL7 modeling, terminology, and publishing tools & processes. You were right on money about the lack of support for novice and intermediate modelers. As long as "a lack of band width" is the perceived problem, the bandwidth problem will just get worse and worse.
You didn't mention Detailed Clinical Models, which is something I would hope that MnM would embrace, encourage, support, and insist upon (and not just because it is my pet project, which is another reason to support it).
This is a chance to create a library of comprehensive, and orchestrated, static models which can be quickly and easily (and safely) used to represent a given domain's clinical content requirements. It is supposed to be a central collection of stuff that can be snapped together and the unneeded parts pruned off, knowing that the terminology and the surrounding RIM-based models all fit together.
DCMs are a way to use a top-down framework--all the way to fairly low level abstractions, as well as a terminology centric, bottom-up modeling which should work hand-and-glove with the top-down approach (so long as we remember we are working on static models of meaning, and nothing else!) when they meet.
I don't recall seeing anything about the lack of a QA process on information models and HMDs going to ballot. We know that that all ballots may not attract the needed, detailed attention to catch errors. It can take hours to read just one or two with the attention sufficient to notice errors. (One of the motivations for DCMs is to address the issue of content modeling quality using the Clinical Statement Pattern which kept showing up in various ballots which all modeled the same thing differently.) MnM needs some process to make sure that the RMIMs, DMIMs, HMDs which go into a ballot are technically correct. It cannot just be the facilitator and the ballot. We need a real QA/QC that can go over models before they show up on the ballot site and get the bugs fixed before they hit the ballot. Again, teach us, and the bandwidth argument becomes a non-issues when there are many hands.
As far as risks this too is something that getting more people knowledgeable about the"why" and "when" will help. Many people just look at the RIM and data types and think we have made things harder than they should be (supposedly just so we can make a living off the confusion and discord as consultants. Just because we know it isn't at all the case, doesn't mean others don't believe it.).
Right now, implementers look at R-MIMs and shudder. People need to look at them and be glad we put all that detail into something they can leverage. This means getting the word out about how to use the MIF to save time and money. We need to start teaching people a lot more about the why of this. Otherwise we just scare them away with our very hard to read (who picked red as a background color) color coded super compressed not-quite-UML.
We need to socialize the need and utility for the RIM/datatypes/vocab/patterns/models much better in the industry. Next HIMMS MnM needs a booth with great big RIM parts people can put together and play with to see what sort of things they can say, then they can pose with their model and one of our MnM co-chairs to remember the moment.
We need to help them understand that they do not need to know how to create v3 messages in order to use the RIM based specification --whether they are in some web/cloud service, as an application API, message, or CDA. (I don't know why we try to teach people how to author a message standard after a half-day intro.) We need to focus our teaching understanding why this methodology works when others will not, what the models mean, and how to work with them in their own systems. We don't need a bunch of people making up their own HL7 v3 message standards right now, we need implementers who can leverage the work which we publish. It is hard enough for one of us to get something right, lets not scare people away like this.
We need to show people how, and why, our methodology does things you cannot do without, and we probably don't want to waste a lot of time getting this together
I don't want to sound like a complainer, there are a lot of great things done in MnM, and, when I have time, one of the most intellectually satisfying things I do in my life is working on modeling some of the complex topics in our laps at the moment. Getting started with the Eclipse tools is a breath of fresh air which will help reinvigorate people. We need more of the talented people who are getting these put together, and need to thank them for liberating Woody, Lloyd, et al from their toils and troubles for years and years (with more curses than thanks, I am sure) so they can focus on teaching the rest of us how to get these thing put together and out the door!
--KevinCoonanMD 02:03, 10 March 2011 (UTC)
