Announcement

Collapse
No announcement yet.

HL7 Message source identification

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • HL7 Message source identification

    I am new to HL7 and have a few basic questions. If I am providing a service where clients send me information in HL7 messages and I have Mirth Connect configured to accept these messages and process them how do I identify the source of the messages? The data source must be identified so as to prevent users from accessing data they aren't authorized access to. Do I assign each client a separate channel (doesn't seem practical and insecure)? Do I assign each client a Organization ID, if so where in the messages would the client specify the given ID? Or is this typically done some other way? Any information would be much appreciated.

  • #2
    Hi jrArAustin,

    Both of your approaches are valid. You could create separate listeners on different ports for each client and provide them the connectivity information. To avoid having duplicate logic in the channel, you can set the destination on all of your listener channels to Channel Writer and have them send the incoming message to a single processing channel configured with a Channel Reader (essentially a "funneling" pattern). For the second approach, you can create a filter rule that inspects the MSH.4 field which in HL7 is the sending facility/organization.
    Gerald Bortis | Chief Information Officer | Mirth Corporation

    Comment


    • #3
      What type of connection is the source connection in your channel? Is Mirth using a SOAP listener to accept messages? Very common for HL7 version 2 messages to be sent over TCP/IP; HL7 version 3 messages are commonly transferred in SOAP messages. Unless all the systems sending use the same transport protocol you may wind up having several source connections. I see Gerald has made a great suggestion to architect your solution so that you avoid duplicate logic.

      Comment


      • #4
        What type of connection is the source connection in your channel?
        Initially I was thinking LLP over HTTPS, but you are correct we will need to support other types of connections.

        Comment


        • #5
          Originally posted by geraldb View Post
          Hi jrArAustin,

          Both of your approaches are valid. You could create separate listeners on different ports for each client and provide them the connectivity information. To avoid having duplicate logic in the channel, you can set the destination on all of your listener channels to Channel Writer and have them send the incoming message to a single processing channel configured with a Channel Reader (essentially a "funneling" pattern). For the second approach, you can create a filter rule that inspects the MSH.4 field which in HL7 is the sending facility/organization.
          Thanks geraldb!
          I like option 2 best. So I am guessing we would assign the MSH.4 value and clients would know how to configure this in their PMS, HIS,... right?

          Comment


          • #6
            Originally posted by jrArAustin View Post
            Thanks geraldb!
            I like option 2 best. So I am guessing we would assign the MSH.4 value and clients would know how to configure this in their PMS, HIS,... right?
            As long as they're populating their HL7v2 messages according to spec (at least in the MSH segment), then it will work.
            Gerald Bortis | Chief Information Officer | Mirth Corporation

            Comment


            • #7
              Originally posted by jrArAustin View Post
              The data source must be identified so as to prevent users from accessing data they aren't authorized access to.
              What are your security requirements?

              Looking at the value in MSH.4 will work, but of course an attacker could put the ID of a trusted system in there, and gain access to everything that trusted system has access to.

              Comment


              • #8
                What are your security requirements?
                HIPPA compliant.

                Looking at the value in MSH.4 will work, but of course an attacker could put the ID of a trusted system in there, and gain access to everything that trusted system has access to.
                This would be a GUID assigned and verified by us. Mostly this needs to be a value that's not easily guessable. Other security measures would include encrypted communications HTTPS, VPN, SSL,... and basic HTTP authentication.

                For example:
                Code:
                GUID: b4e26387-dc74-41a4-9a37-0e22c8ad5d94 = Client 1
                GUID: c4baa959-69d2-43d9-a07a-90f9ed2be6f7 = Client 2
                ...

                It's easy to guess or fat finger the client ID (1, 2, 3,...) as they are sequential but the GUID would be impossible to guess or enter accidentally.

                Comment

                Working...
                X