Within our scope was making recommendations in support of a short-term value set infrastructure enabling Stage 2 quality measure deployment. Out of scope was the longer term infrastructure.
The recommendations we discussed are listed below briefly.
- Establish NLM as a single authority to validate value sets used in Stage 2 quality measures.
- Ask ONC to expedite recommendations made by the workgroup in January this year (especially see slide 20) and by the Vocabulary Task force in April of 2010 (powerpoint).
- Specify the standards to use for exchange of value sets. Two choices were presented:
- IHE Sharing Value Sets
- HL7/OMG Clinical Terminology Services 2.0
- Enable web access for human and machine readable consumption.
On the first two topics, the workgroup appeared to be in good agreement.
CTS2 and IHE SVS
I was caught a bit off-guard with respect to recommendation #3 becausethe workgroup had already developed a consensus on recommending the IHE SVS profile on the call last week. It appears that there were some observers that were concerned about the use of that profile, especially since such a recommendation appeared to exclude the use of CTS in the architecture (even though it doesn't as I explain below).
The situation is a bit confusing for many: The IHE Sharing Value Sets profile is a simple implementation of two of the APIs described in the CTS 1 and CTS 2 specifications. It is designed for a very simple use case of searching for and downloading value sets. It is NOT designed to support broad management capabilities needed to maintain, validate or curate value sets.
The CTS standard originated as version 1.0 in HL7. CTS 2.0 became a joint HL7/OMG work effort, with HL7 defining essentially a functional specification, and OMG defining an implementation of that functionality. This pattern has been used in many HL7 / OMG collaborations.
I think the reason that the workgroup struggled with the question is because the scope was sharply defined with respect to implementation urgency. If you are going to develop a vocabulary (value set) maintenance infrastructure, you should be applying an architecture that accounts for standards like CTS, whether your view be short term or long term. However, regardless of what the architecture is, for the purpose of deployment of value sets to Health IT systems. They don't need an extensive API in order to access identified value sets. What they need is very simple.
As always, when posed with an either/or question, the answer is usually to restate the question. Both CTS2 and IHE SVS are pertinent and appropriate for the infrastructure. The Infrastructure should be oriented around CTS (long term), but APIs to access and download value sets should include IHE SVS (short term).
Enabling Web Access
On the final recommendation, the workgroup also struggled a bit. We kept falling into the trap of solution vs. requirement. The key requirement for web access is that there be a single source of truth for value sets. Whether that requirement is met by a single host (web site) through which access is granted, or multiple hosts accessing a singular database or service supplying the content, or a model of deployment supported via replication or federation is not material. We were well in agreement on there being a single source of truth for value set deployment but kept getting confused in drafting our recommendation by specifying solutions that meet that goal.
Coordination
There was insufficient time for me to bring up one issue that I am concerned about. At present, NLM, AHRQ, CDC and ONC are all expending efforts on managing vocabulary and/or value sets for a variety of different purposes. I'd like to see better use of HHS resources applied to the management of vocabulary and value sets, without so much duplication of effort.
No comments:
Post a Comment