Interoperability
is a mammoth, catchall topic on the minds of healthcare IT stakeholders everywhere. For
most providers, however, the term remains an abstraction. For patients, it
likely has little meaning. What matters for both is not some lofty ideal of
“interoperability,” but rather improved health and health care experience.
What does
interoperability look like when it works to assist providers to better serve
their patients? In this series of posts, Dynamic Health IT will look at a few
concrete examples of breaking down barriers to health information exchange. Like
any physical engineering project, many parts of it are far-from-glamorous. But
doing the grunt work is essential to inching closer to fully portable,
patient-centered health data.
Making immunization records accessible
Immunization records are historically one of those essential pieces of health information that patients and caregivers have had difficulty tracking down and toting around to each new provider. Providers, meanwhile, often lack assurances that they are seeing a reliable immunization history. The idea behind connecting providers to state immunization registries is to make sure patients receive needed immunizations in a timely manner, removing the headaches of scattered records.
Immunization records are historically one of those essential pieces of health information that patients and caregivers have had difficulty tracking down and toting around to each new provider. Providers, meanwhile, often lack assurances that they are seeing a reliable immunization history. The idea behind connecting providers to state immunization registries is to make sure patients receive needed immunizations in a timely manner, removing the headaches of scattered records.
 |
| Credit: NIH |
In practice,
each state has different data exchange needs and policies. Providers – often
small private practices – must work with EHRs or practice management companies
to navigate the requirements. For the last year, Dynamic Health IT has been
increasingly involved in applying our knowledge of HL7 data, information
exchange methods and development to bridge this gap.
In Texas, we
worked to establish an HL7 interface and secure FTP connection to the state.
Through iterative testing, we then adjusted EHR output from the client system
to fit state HL7 requirements.
This test
case then came to serve as the template for future implementations. Drawing on
experience with HL7 interface design and knowledge of other state specifications,
we have worked to create a “master message” generated by the EHR. Fields that
are optional in some states will be ignored, while in other cases our HL7
interfaces will make tweaks so that these messages will pass testing and be
submitted efficiently through any transport method.
In Georgia –
whose immunization registry bears the clever acronym “GRITS” – we wrote a web
service to pick up immunization messages dropped from an HL7 interface into
folders. The web service knows the client credentials and expectations from the
Web Service Definition Language (WSDL) on the GRITs site. The two sides talk to
each other broker the exchange of information, with our web service pulling
down acknowledgments of received messages.
