Q&A with NIST interoperability contractor
When the National Institute of Standards and Technology recently awarded Aegis.Net a $6.25 million contract to test standards and interoperability as part of meaningful use of electronic health records, it highlighted the rising importance of interoperability and data exchange.
The goal is to make sure that health IT systems have standards in place according to specifications and can effectively exchange information.
The initial emphasis of the NIST contract will be on testing the standards for meaningful use, but it will also provide test tools to support electronic health record communication and electronic clinical document exchanges, such as for e-prescribing, lab results, immunization and patient administration, as health care moves in that direction, according to a recent NIST announcement in Federal Business Opportunities.
In another testing effort, Aegis.net is partnering with the Certification Commission for Health Information Technology (CCHIT) to use its testing software, the Aegis Developers Integration Lab, to test interoperability for the EHR/HIE Interoperability Workgroup, an effort led by the New York eHealth Collaborative (NYeC) that includes 15 states and 34 health information exchanges (HIEs). Aegis will work with CCHIT to make sure that the interfaces are consistent between the health IT and HIEs across multiple states and systems.
The open source Developers Integration Lab (DIL) is the heart of Aegis’ testing, according to Mario Hyland, senior vice president and founder of Rockville, Md.-based Aegis.Net Inc. Hyland spoke with Contributing Editor Mary Mosquera at the Oct. 17 conference of the Open Source Electronic Health Record Agent (OSEHRA), a nonprofit organization formed to modernize VistA for open source and to contribute to the VA-Defense Department’s integrated electronic health record (iEHR). Aegis.net is a participant.
Q: Why is interoperability so complicated?
Hyland: What we have found technically is that even when people wrote good code, interoperability was a significant challenge. There are so many dependencies around the technical stack, the Web services, the software that the system was running on, the operating system, and various patch levels. If people were not aware of how they changed systems, they could actually break interoperability.
We need the developers testing while they are building, even the software as it is being built to be tested against future and backwards compatibility. The actual transport layer is critical. You cannot determine if anyone is compliant to a message specification if we can’t interoperate.
Q: What will Aegis.net provide the Interoperability Work Group multi-state, multi-HIE effort?
Hyland: When the IWG wants to certify a vendor’s product, they will have a very rigorous process. We’re going to use our Developers Integration Lab to do that automated testing, which will prove that the vendor is both compliant through conformance in the structure of the message but also is interoperable. Vendors who are trying to sell their wares can prove that they can interoperate and are compliant. Then they can show those results and prepare to go to the IWG.
Q: Why has the need for testing become so critical?
Hyland: In days gone by, a CIO or CTO running a hospital system controlled that domain. Now with health information exchanges, all of a sudden his ability to operate depends on a CIO down the road or a CIO in a hospital system across the country. No longer will the CIO be able to defer costs around upgrades and keeping current specifications. He’s going to have to be very careful with his budgets to determine that he remains compliant and interoperate.
The CIOs that recognize this risk want to test, and the organizations that are responsible for governance to make sure that these exchanges keep operating want to test.
The DIL will do constant monitoring and constant testing of all of this. Aegis builds systems to ensure interoperability after organizations go live. Our whole methodology is to make sure that those gateways continue to operate. When one person plans an update, we don’t want to break what’s going on.
Q: What are some of the standards for which Aegis.net can test?
Hyland: For interoperability, we use SAML (Security Assertion Mark-up Language) 2.0, which is a wrapper, an envelope. (SAML enables web-based authentication and authorization uses.) Inside of that SAML envelope, we look at the purpose for its use and the role. So a doctor might need some information for a patient by name for medical treatment. When it arrives at its destination, staff can look at that SAML envelope and know that this is coming from a doctor and it’s for treatment, so they can route that through their workflow differently than if the message was coming in from, say an advertising group.
Access/consent policies (ACPs) allow patients to choose which doctor gets to see what part of their electronic health record. Some people may have visits to a psychiatrist or psychologist that they do not want to share. The patient is allowed to ensure that when another doctor for treatment purposes needs to see about their allergies and medications, that information is dynamically on demand, created minus those elements that the patient did not wish to share, and access consent ensures that only certain providers get to see it unless it’s in a break glass situation. This is all contained within the SAML wrapper.
Once you have validated that the doctor has a valid purpose for using the information, you look at who the patient is, the demographics, and look within your system if that patient has been treated. It needs to make sure that we are talking about the same patient. We need to build systems with matching algorithms that are sophisticated enough to ensure that they find the right patients.
Beyond that, it is the exchange of documents and information, such as HL7 standards, the Consolidated CDA and different types of document formats.
Q: What’s just over the horizon for Aegis.net?
Hyland: We need the communities working with us to test to validate the lab and to ensure that the testing is right because we believe that as the community comes together and works with us to make sure that the DIL is testing right, it becomes a reference. The DIL will make for tremendous efficiencies. And when peer-to-peer communications find they can’t interoperate, maybe because of an upgrade to Java and the Java stack, they can use the DIL to test their endpoints against a reference system to see which one is misbehaving, and then they can work on the whys.
We also believe that the DIL is critical to helping small EHR vendors stay viable. Otherwise, they’re going to be gobbled up, or it is going to be difficult to compete with the big vendors.
We’re also taking the DIL to universities. We’re helping their health informatics groups how to test and set up an open source EMR and how to start interoperating, taking a page from Vint Cerf, when he was with DARPA, and he got the universities exchanging information. If we use the DIL to help the universities prove that their system works, then the universities can start exchanging. I want to drive global interoperability.