CMDB class for HL7 interfaces and FHIR APIs

[changeman]

We are working on fleshing out our SN CMDB instance with logical CIs and have struggled with finding a default CI class suitable for healthcare interfaces, both classic HL7 v2 over TCP/IP as well as FHIR APIs.   At its simplest, an interface sends data from one system to another, whether triggered to push or pull, synchronous or not (most HL7 being synchronous).  In terms of  CI relationships, an HL7 interface connects a sending endpoint to a receiving endpoint, whether there is middleware in the middle (Cloverleaf, Rhapsody, Mirth, Corepoint, etc.) or not.  Ideally, an interface CI would connect endpoints at two levels: server (with IP/listening port or URL listed) and application, or at least through a server CI link to an application/business application CI. 

We couldn't find anything in the list of default CIs (going off of documentation for Tokyo) that would clearly accommodate this concept, but I'm sure we're not the first ones facing such a challenge.  One recommendation was to use cmdb_ci_service, which is defined as "IT Service that directly supports a Business Process (ITIL)." However, its suggested relationship seems to imply closer alignment with one of the endpoints whereas in our thinking the endpoints are equal relationship partners.  Service as a CI and an actual SN service might confuse matters more.

How have other organizations configured their HL7 and FHIR interfaces in SN CMDB?

[Ralph Hand]

We have the integration engine coded as an application CI and do not code the specific interfaces.   It is on our roadmap to do this, as it's extremely valuable information for incident response and change planning.   

It would be extremely helpful to have a CI class specifically for these types of interfaces.

I can also see a need to be able to document APIs in the same fashion

[Josh Baumann]

We haven't tried tackling this area yet in our CMDB.  Like Ralph, we have Interface Engine as an application service but don't break it down below that level.  We have enough problems trying to get our application owners to keep their relationships with infrastructure up to date.  This has come up before at our organization and not just within the EHR.   We were considering a new custom CI class like 'data exchange' that could be used more globally for tracking exchanges between systems and also among partners. We've got a lot of owners of this type of information in our organization and would like to centralize this in a way that is useful to everyone.    

Would be interested to hear if anyone has used individual CI records for specific interfaces instances.  

[s4scott]

To address this in my organization, we created a custom class named "Integration" to capture both API and ETL style connections between applications. Currently it is can support the identification of inbound, outbound and internal transformation types, so that when BizTalk or another ETL tool is used the entire workflow can be modeled.  Where this is particularly useful, is when a single inbound integration is tranformed and sent to multiple outbound integrations. 

As I understand it, the SDLC Component CI should be capable of replacing the custom Integration class we created for these types of CIs. We are going to evaluate that as we look towards Tokyo. 

[changeman]

Thank you so much to everybody for their feedback.

s4Scott, thanks for pointing out the SDLC Component CI coming up in Tokyo.  We'll be on San Diego for a while, so I can't really check it out in the application (heck, I can't even find it on the list of CMDB tables in Tokyo), so I'm going off of a brief description in this SPM/APM article.  A couple of paragraphs there read similarly to the description of Service CI, that is making the component part of an application, whereas in our approach an HL7 interface as a CI is related somewhat equally to the two endpoints it connects (the main difference being the direction of the data exchange).  But a subsequent paragraph says "The advantage of the By SDLC Component view is that you can directly view all the application services and business applications that are related to an SDLC component," which seems to imply that it can link applications unrelated to one another except for the exchange of data (in the case of HL7 or API interfaces).  I guess it would be the "infrastructure" type of the SDLC Component that could function in this fashion?

Also, can you share how much work went into the creation of the custom CI and goes into its maintenance across upgrades?  The recommendations we've received so far advise being very careful with regards to custom CIs or simply discourage it from the maintenance point of view).