With CMS promoting notifications as a condition of participation, we at Ai have been looking at ways to continue iterating and modernizing our industry-leading Encounter Notification Service® (ENS®), which already supports many of these requirements today.
On December 11th and 12th I attended my first “Da Vinci” Connectathon. I’ve been to several FHIR Connectathons in the past, but this was my first Da Vinci–focused event. The event was held in Independence Blue Cross’s Innovation Center in Philadelphia (my home city for more than a decade). Connectathons are events where various participants come together to test implementations of various standards–based use cases. I’ve been watching and balloting the Da Vinci Project’s efforts since their inception, but this was the first time I’d had an opportunity to implement one of the Da Vinci specifications. At this event, several Da Vinci Project use cases were tested.
The Da Vinci Unsolicited Notifications Implementation Guide (IG) supports the use case for enabling providers and payers to receive alerts when activities occur that impact patient care. An obvious primary use of this IG is to support notifications for an unplanned emergency department, inpatient, or ambulatory visit. This IG supports some of the requirements CMS suggested as a condition of participation for hospitals in the Patient Access proposed rule and is an obvious fit for our ENS solution.
We had already deployed an HL7 V2 to FHIR converter using FHIR DSTU2, DSTU3, and R4 as part of our successful integrations with our Ai FHIR Layer and our Unified Landing Page (ULP) products. We had also contributed some of that work to the HL7 V2 to FHIR project. Both were nearly perfectly aligned with the Da Vinci case. What I needed to do during the two-day event was to show that the V2 converter could produce notifications from existing messages stored in ENS. As Ai was the only vendor to bring a customer to this event, it was incumbent on us to ensure that others could successfully test their implementations. Three other organizations provided servers to receive notifications (a payer, a testing tool, and the vendor providing the reference implementation for the IG).
Most of our work was already done: The MessageHeader, Patient, Practitioner, Organization, and Location resources were already mapped to FHIR from the appropriate HL7 V2 message parts. To get everything together, I had to integrate new mappings for the Insurer (IN1 and IN2) and the Guarantor (GT1) into the Coverage resource, add the Next of Kin and Guarantor (NK1 and GT1) to support RelatedPerson resources, and update mappings for DG1 that we had contributed to the HL7 V2 to FHIR project for mappings to the Condition resource. I then created mapping tables to map from ADT trigger events (e.g. A01, A02, A04) to Da Vinci unsolicited notification events (e.g., admit-notification, discharge-notification), and to handle some additional Da Vinci IG–specific mappings. This process took about 3 days of analysis, system configuration, and testing.
I needed to add one small feature to the V2 converter so that it could recall a previously mapped resource (e.g., Guarantor) for subsequent mapping from later segments. This was to support some vagaries in how different systems might communicate the subscriber information which could later be referenced by the Coverage resource. I also needed to address a minor compatibility problem between message versions and withdrawn fields in later versions of V2 (the converter component works with multiple HL7 V2 versions). Additionally, I spent some time experimenting with adding FHIR profile tags based on message content, but later decided that profile validation would need to be a separate microservice. Altogether, these modifications took around a day and a half.
During the testing we identified two potential areas where the specification or test scripts needed to change: an additional field of great value (reason for visit) that should likely be included in the specification, and a bug in the HAPI FHIR Client when sending an asynchronous message using the processMessage API. We were able to apply metrics we captured on field usage from existing implementations to validate which fields would be generally available and beneficial to the use case. The bug we found in the HAPI GenericClient is one which causes it to throw an exception when there is nothing more than a “200 OK Response” on an asynchronous message. Asynchronous messages don’t always expect anything back (according to the $FHIR process-message operation), but the client code is throwing an exception when no content is returned. I believe this is resolved in later releases of HAPI, and I’ll be testing that at the CMS Connectathon on January 7th and 8th (you will hear more from us on that topic in the future).
We plan to continue our support for these and similar FHIR profiling efforts to further improve our solutions.
Are you interested in receiving FHIR Notifications or Subscriptions from the Encounter Notification Service? If so, please drop us a line, we are interested in hearing more from you about how this might become a valuable addition to ENS
-Keith W. Boone
Keith Boone
Informatics Adept, Audacious Inquiry | Keith Boone has two decades of standards development and implementation, and more than a decade of standards leadership experience. He represents Ai to Health Level 7, Integrating the Healthcare Enterprise and diverse other bodies developing health IT standards and implementation guides. He brings his experience in natural language processing, information retrieval, machine learning, XML and health IT standards to augment Ai’s product offerings, and in standards development and training to assist regional, state and national initiatives in raising the bar for health information exchange.