As a former employee of an EHR Vendor, I'm well aware of VSAC (the Value Set Authority Center) as a source value sets (I also played a role in writing the HIT Standards Committee recommendation for the creation of VSAC).
As an Informaticist, I'm also well aware of LOINC Value Sets and SNOMED CT Value Sets for COVID that many have published.
As an Interoperability policy geek, I am also familiar with the ONC Interoperability Standards Advisory COVID-19 content.
As a highly educated expert, I CANNOT, for the life of me tell you which of these is the most authoritative content to use for COVID-19 reporting, either for what had been reported to NHSN, or presently for HHS Protect, or for eCase Reporting. I do know enough to build a pretty damn good value set of my own for a system that I'm responsible for developing, but that's NOT what I want. Developers don't need more work, we need experts to do their work, and make it readily available for others, and not just to publish it, but also to Market it for their jurisdictions so that it can be found.
I can also tell you that there's simply FAR too much data available to developers to let this situation continue.
Here are some rules for organizations responsible for these value sets to consider:
- Figure out where the developers who have build systems get their information, and publish to those sources where they can get more.
- Consider cognitive load on developers. Don't give them hard to remember web site names with 80 character URLs to get to the data they need. Register a reasonable and memorable domain name. Make the information easy to find. Remember that not every developer works for a hospital or an EHR vendor.
- Remember that data distribution and publication needs different governance for access that data creation. If you have a system that supports creation, don't force a developer to get credentials for that system just to access data, just give them a URL. Sure, give them a way to share an e-mail address for updates, but don't force them to create ONE more login just to learn what they heck they need to do.
- Make sure that the distribution system has a way of reporting that data (especially value sets) using standards. Sure, CSV files are good, but come on, we're trying to work on modernization and APIs. Put the same effort into your distribution mechanisms with respect to APIs and publication that you expect developers to put into the systems that will use the standards you are promoting.
<rant>There's absolutely NO EXCUSE for a system designed to support FHIR to have an easily accessible CSV distribution mechanism for value sets, BUT not to have a FHIR ValueSet distribution mechanism.</rant> - Curation of a value set is a responsibility that steps up as demand increases. If you are responsible for curating a value set and the demand for updating it steps up due to an emergency. Quarterly may be fine for things that change annually, but when the situation is changing week by week, changes are also needed week by week. Yeah, I know, funding and all that ... figure it out, that's part of what being responsible means.
Of course all my International friends are simply going to tell me that the fundamental issue is that the US does not have a coordinated national infrastructure. I can't argue with that. Every agency is a plural of services, centers or institutes, I just wish ...
I cannot argue, nor would I want to, that the dominant paradigm for the national health IT infrastructure has been (said positively) to let 1000 flowers bloom. Whether it is the commercial leanings of clinical care infrastructure or the "stovepipe" funding of public health the issue is prominent. Health IT does not work well this way and we see the impact of it on desired outcomes all of the time.
ReplyDeleteBeing involved in electronic case reporting (eCR) and associated with RCKMS, however, there are at least two major reasons that trigger code value sets, may not be the best example of this and need to have security controls and not just be freely accessible value sets.
• Number 1 is that trigger code value sets effect what data are transmitted from clinical care - it can effect a legal disclosure. The addition or subtraction of such codes needs security. Users need to verify that the codes are from a valid source, And they need to know that they have not been tampered with. In eCR, while the trigger code sets can be large, there is a forced validation on loading step that is instituted for this purpose. A similar project at the CDC is projecting the need to use SMART on FHIR backend services for this purpose going forward.
• Number 2 is that trigger codes change during an outbreak. Not only is it important that EHRs report eCR, but it is important that they keep their clients up-to-date with the most current trigger codes to report properly. Unfortunately, these updates are not always done and users need to be prompted to comply. There is a registration step in front of the eCR trigger codes because we have found that the alerting of implementers that there is a new trigger code set available (and hence having their communications parameters) is an absolute must for compliance.
I hope this, now long, comment helps with a further understanding of some of the issues of public health reporting. We are all in on better coordinated HIT infrastructure, but it is also important to grapple with the full requirements to understand what that better coordinated infrastructure should be.
Sorry, the previous comment came from John Loonsk.
ReplyDelete