Functional Governance

When is a requirement not a functional requirement?  When it gets into implementation details.  One of the discussion going on in HL7 is around a project currently under development which seems ready to specify implementation rather than functionality.  I say seems because I have only the project scope statement, and statements by one of the committee leaders pushing the project forward to go on, and that's where I have gotten that impression.  I haven't yet looked at the draft materials that the project has produced because they aren't to my knowledge published yet.

I won't go into all of the details.  If you've been following some of the HL7 list traffic, you already know those.  HL7 develops several kinds of standards.  One of these are functional models.  These are sets of requirements on specific kinds of healthcare IT, like the EHR Functional Model or the PHR Functional Model.  Others types of standards are messaging and services standards like Version 2 or Version 3 (messages and documents), or Clinical Decision Support or Terminology (Services).

So, the problem here is one of how vocabulary should be used in a functional model.  For a specific use, it's certainly acceptable to say that X shall be able to be communicated using Y vocabulary.  For example, the system shall have the capability to exchange laboratory results using LOINC.  But other uses get into implementation.  To say that Problems shall be able to be stored using ICD-10-CM might go to far, depending upon the purpose of the system. 

Storage is more often than not, one of the implementation characteristics by which functional requirement to exchange information is met.  But there are other mechanisms by which that same functional requirement can also be met.  I know of at least two external third-party vocabularies whose claim to fame are that they are A) more granular than vocabularies like SNOMED or ICD-* and B) are able to be easily mapped to either.  If a product stored information using either of those vocabularies was able to regurgitate information in an exchange using an appropriate vocabulary, then it meets the functional exchange requirement.  But what it does internally is left up to it.

Now, in this particular case, it's clear that this particular project has a favored vocabulary, and that vocabulary is also either completing, or in the process of being mapped to another, broader, more widely used vocabulary.  And the favored vocabulary is a licensed product that is not as readily available in some regions as the other one.  And while the licensing costs are rather inexpensive as vocabularies go, there's still substantial time and enery spent A) verifying suitability for purpose, B) licensing the product, C) accepting delivery and incorporating it, et cetera, especially if an alternative one is already available and licensed.  And the cases where it surfaces as a functional requirement are also important because it could change a lot of implementation details, or just a few.

So, the question is, how should a functional model specify use of a terminology.  That's an interesting question, and not one that can be answered in a few days (I think).  But I think it needs to be answered before this particular project will be ready to move forward.  But, the pressure is on to push this project forward because balloting deadlines are nearing, and the project team (and committee leadership) thinks they are ready to publish.  Those are not necessarily good reasons to move forward.  There are reasons why we have this "three-tiered" governance model in HL7 (Committee, Steering Division and finally TSC).  So, I'm pushing back and saying this particular problem needs to be resolved before I would feel comfortable voting yes to move forward with the project.

Another part of the issue has to do with where and how it is appropriate to select a specific vocabulary for a specific topic.  I'm certain that particular domain expertise is not widely present in the EHR committee, although it may be quite present in the project team.  I do not want to see the HL7 Functional Models becoming a back door to the selection of vocabularies without there being some way to ensure that that whole process encourages appropriate domain specific review.  Futhermore, "requirement of a vocabulary" in a particular FM should be predicated on a level of acceptance of that vocabulary as being appropriate to the purpose.  But that isn't a EHR FM sort of decision to make, at least not as I understand it from the perspective of HL7 governance.

Essentially my pushback is that A) I don't want someone to tell me how to implement the system, I want them to tell me what they want it to do, and I'd like to know how that will be ensured in not just this project, but all projects with a similar issue (because this isn't the first time I've encountered this), and B) how can we be sure that requirements to use a particular vocabulary are vetted first in an appropriate domain before they show up as product requirements.  If we decide to trust the process used to create the vocabulary, and its acceptance for a particular purpose is well established in the industry, I'm OK with that.  What I'm not OK with is using the EHR Functional Model as a way to gain acceptance for a specific vocabulary without seeing the vetting process happen.

Of course, some people probably think I'm blowing steam, and way over the top.  One of the e-mails seemed to indicate that.  That could be.  I don't know this particular vocabulary from Adam, it's the first time I've heard of it, I'm not a licensee and cannot look at it, and I don't know if it is suitable for the particular purpose it is being promoted for, nor would I be even able to tell if it was.  But I also know that most of the balloters on EHR Functional Models would be in my shoes as well -- so, I'll push a little bit more.

If nothing else, this project has raised an important issue through the HL7 governance process, and those issues will get put on the table and I expect, be addressed.  That's all I'm asking for, and that is after all, the function of the governance process.