I have been at the ONC Interoperability Forum in DC for a few days and I had an opportunity to discuss NIEM for Health with a very well respected former government official whose perspectve I respect very much. He has a long history with standards development, especially in healthcare and with a government perspectivie. The following is his perspective and I tend to agree (I paraphrase here interspersed with some direct statements).
NIEM was established as a government program to create a more consistent way for state, local, federal and tribal governments to exchange information. It has always been funded by federal agencies, and has a governance structure that reflects that. It has been useful in getting law enforcement, government programs, social security, and other programs to exchange information in a consistent way. That is their swimlane. They make standards by government, for government.
OMB Circular A-119 (see https://www.whitehouse.gov/wp-content/uploads/2017/11/Circular-119-1.pdf ) stipulates how government agencies (like ONC) should adopt standards within regulations. It says that the government agencies should adopt consensus based voluntary standards to a preference to Non-consensus, industry, or government-unique standards. NIEM is a "government unique" standard. ONC is required by law to report on all of the standards that ONC adopted through meaningful use, and to explain any deviations from adopting standards that were non-consensus based or government-unique. There are lots of important reasons why governments should not set standards (think of tariffs and other ways to block trade through government specific or company-specific standards that would benefit one group or one company), and so NIEM would need to become a full-fledged real SDO if they are serious about health care.
The NIEM process is not a bad one, but one that is unlikely to scale to encompass healthcare. They are not particularly strong in terminology binding processes, and there is very little knowledge of how the current medical terminologies work.
We should not support government-unique standards that lack shared expertise in healthcare developing yet another set of standards when we desperately need people to mature and use the standards that we already have. Why is it beneficial to organizations to use a new, government unique standard, developed without significant understanding of healthcare, that lacks good mechanisms for vocabulary binding, and that duplicates years of work in HL7, LOINC, SNOMED and other consensus based SDOs?
Unless there is a compelling reason for developing yet-another set of standards in healthcare, change NIEM into a fully transparent SDO, and reinvent the wheel, why would we devote any energy here? Why not use HL7 and FHIR-based standards in prisons so that prisoners get the same level of care and information exchange as people in other parts of the healthcare sector? Why not understand how to interface between human services not only within government (TANF, etc) but also with non-profits, NGOs, and other care agencies? Why would the standards community support yet another standard that has no clear advantages, gets in the way of OMB directives, and pulls resources from other initiatives that would do more good?
Comments? Thoughts?
Replies
There are a lot of misconceptions about NIEM that need to be corrected. First, NIEM is not a standard. It is a framework and methodology to facilitate semantic interoperability across domains. This framework is a way that is agreed upon through a governance process as a basis for creating true standards for the automated exchange of information between domains that have different languages and constructs. For such standards, conforming to NIEM means using the harmonized data components and adopting the naming and design rules which have been adapted from ISO 11179 (which is an SDO). The way to specify a standard under the NIEM framework is to use the design specification called an Information Exchange Package Description (IEPD) which is a template designed initially by industry not government. NIEM is also not a federal standard in any way that is envisioned under OMB Circular A-119. The components of the NIEM data model consist of core data elements pertinent to 2 or more domains plus a set of unique data components of interest mostly to individual domains.
The developers and participants in defining NIEM are also quick to point out the NIEM deals only with information in motion between systems. It was never the intent that the harmonization of data between domains would be applied as a standard applicable to the schema in individual systems.
NIEM is also not a government-unique standard. The "N" in NIEM is very intentionally used to state that this is not a Federal standard imposed by the Federal government. It is, in fact, a consensus-based standard emanating from practitioners from local, state, federal, territorial, tribal and private sector organizations. In short, NIEM supports the kind of consensus-based standards development process that OMB Circular A-119 calls for. There is no doubt that a lot of the use cases and applications of NIEM serve government purposes, but here government means not just the federal level. It is true that a lot of the cross-domain needs for interoperability serve the purposes of agencies of government, mostly at the state and local level. The federal government generally does not dominate the domains of justice, human services, and other domains when it comes to delivering service. The actual development of the NIEM data model was led mostly by non-profit membership-based organizations that focused mostly on practitioner inputs from various state and local governments and the tech industry that serves these markets. The original start to NIEM came from a paper written by a non-profit technology consortium representing IT companies(the IJIS Insitute).
NIEM goes to great lengths to use authoritative sources for creating standardized exchanges, relying wherever possible on existing standards coming from established SDO's such as ISO, ANSI, Oasis, etc. There is no reason for a health domain to reinvent standards that already exist in authoritative references such as SNOMED, LOINC, ICD-10, etc. They can all be incorporated by reference into the NIEM structure.
NIEM is very intentionally limited to fostering semantic interoperability and says absolutely nothing about the means of communicating data content between systems or the messaging protocols. From its inception, NIEM was so constrained in order to recognized that communication protocols will emerge probably faster than a consensus about data standardization. When NIEM was designed originally, the emerging innovation was XML which was a revolutionary concept beyond the FTP capabilities that were then the state of the art. An important premise of NIEM was to build something that could accommodate new ontologies and messaging protocols like as happened with restful APIs without losing the power of an approach that deals with semantic interoperability across domains. To put it succinctly, there is no basic reason why NIEM conformant exchanges cannot take full advantage of FHIR protocols for transmitting the exchanges.
The key ingredient to developing sustainable standards in any field is to create a governance process that generates a consensus-based on full stakeholder representation and participation. The NIEM governance model was designed with this in mind, inviting each important domain to create a steward that would bring together the relevant stakeholders in each domain to freely contribute to building the consensus. The CIO of the Department of Health and Human Services committedin writing to taking on this role for the health domain, but subsequent administrations have not followed through to bring the health community expertise to the governance process the way other domains have done. There certainly has been a fervent desire of NIEM program managers to bring all relevant knowledge and expertise to solve these interoperability problems across boundaries.
There is not a compelling reason to build yet another standard, but NIEM does not purport to do so. There is, however, a compelling reason to find a way to build cross-domain information sharing standards that can conform to NIEM and to existing standards in the domains so engaged. State prescription drug monitoring programs used NIEM effectively to create a set of exchanges for interstate exchange of controlled substance data while creating a highly secure messaging service between the states to transport the data. There are many other cross-domain examples described at niem.gov.
NIEM is not appropriate for every exchange of data or information. But when the requirement is for the transfer of commonly understood data between disparate domains or disciplines, the NIEM methodology with it's naming and design rules provides a pathway to creating specific exchange standards that have proven to be less costly and to lower risk of implementation as well as reducing development time. As we try to eliminate the enormous waste of resources in duplicate data entry and improve the quality of data as well as the timeliness of information to improve decision making, NIEM can be a helpful guide to this new way of doing business.
Noam,
1) I think you and the "former government official" with whom you spoke are missing the point of the current vision for NIEM Health. We are not attempting to create any new healthcare standards. Rather we are attempting to map HL/7 (v2.5.1 and FHIR) data models to equivalent NIEM data models so that the NIEM domains that are using health-related elements (whether we like it or not) can at least exchange semantically equivalent information between NIEM non-clinical domains and the clinical healthcare domain.
2) Those of us now working on NIEM Health do have a strong understanding of healthcare terminology binding processes and strong knowledge of how current medical terminologies work. I was a representative for NYS HHS on a number of HL7, ONC S&I, and EU-US standards working groups earlier this decade and stay on top of their work each week. Perhaps you and your colleague were thinking of folks from the ONC who led NIEM Health in previous years since 2012?
3) I agree with you that prison infirmaries should, must, make use of clinical standards to exchange healthcare information within the prison system and with community healthcare providers. Meaningful Use and MACRA requires it. But there are many other scenarios in which non-clinical domains need to be able to exchange health-related information without incurring the costs of purchasing and maintaining a fully HL7-compliant EHR system just to be able to exchange a modest and usually tightly constrained set of information that just happens to come from a provider's EHR system. They need a stepping-stone to enable access to this information in a form that they already support - NIEM. That is where the idea of a NIEM-to-FHIR (or v2.5.1) bridge and associated USCDI NIEM-HL7 data mapping comes into play. We enable these NIEM-based domains to get access to HL7-standards based systems via the bridge. We continue to support, rather than attempt to replace, the HL7 standards. While at the same time supporting the NIEM requirements of the non-clinical domains.
Whatever you and your colleague think of NIEM from a philosophical point of view, it is a reality for Federal, State, Territorial, Tribal, and now Interntional/NATO agencies. Rather than tilting at this windmill, it would be more productive to respect their requirements and work towards supporting them in a way that doesn't add to anyone's standards burden, nor undermines anyone's existing investment in technology/standards.
Brian Handspicker
NIEM Health Technical Lead
bhandspicker@irishealthsolutions.com
413-672-8210
Thanks for your thoughtful reply. Again, I have no ax to grind against NIEM. But I do note that just about no one from HHS was on that e-mail from you after the meeting (I really only saw ACF people on it). I see no ONC engagement, no real engagement from the HL7 community.
And you did not address in your comments the fundamental governance issue that NIEM is a "by government for government" activity that does not really apply to non-government players.
I'm glad to see substantive engagement with this important piece of the I/O journey.
I think there is an alternative 'formation story' for NIEM at least as I saw it emerge (pre HL&). I worked on standing up the original Human Services NIEM domain while SOC was sorking with ACF in 2011. NIEM was, and I firmly believe remains committed to it being a "national" rather than a "federal" standard. By defnition a national standared is created by the various communities that are destined to use the standard - so rightful and smartly should be the core of the designers.
Frankly, that is one of the most attractive aspects of NIEM for me - it is actually supposed to and has proven to thrive on a broad, multi-sector/multi-domain approach -- starting with naming the domain to selecting and then defining high priority exchanges and their definitions - while leveraging other authoritative sources for many elements. Then it's all put into a respository (at Georgia Tech) and is open and avialble for all other domains to use, for free.
There is a profound lack of understanding and/or past experience/interest/willingness to engage between HL7, or FHIR in it's newest (PROPIETARY) and other standards.
I am very encouraged that we - LGT - are hosting these important conversations. An emerging concept: NIEM on FHIR may provide a promising pathway.
We'll plan next Friday's (8/30) call to review the Person Matching template (V2) and propose forming our second Project team (NIEM on FHIR), and see if we can generate something of value for the communities.
Daniel
Thanks, Daniel. I am not sure why you think HL7 standarda are proprietary. Actually, it is NIEM standards that are proprietary if you read OMB A-119.
Noam
I'll look int OMB A119 more. By propietary i understand that HL7 has a membership fee shceudule and charges individuals/organizations to get access and participate in their processes. NIEM's definitions and processes are open and available to anyone to use. What am I missing?