This appendix describes the best practice for deploying them in separate domains.
From deployment perspective, it is best to install HL7 interfaces (implemented using SOA for Healthcare) and X12 HIPAA EDI interfaces (implemented using the B2B infrastructure) in separate domains for the following reasons:
Operation and on-going maintenance: The healthcare user interface (in SOA for Healthcare) and the B2B console point to the same database instance and both them show HL7 and X12 EDI messages. For that reason, running them in the same domain to show both HL7 and X12 HIPAA messages can create operational, audit, and other maintenance issues.
Compliance: The users of X12 HIPAA EDI data typically should not have access to clinical integration (HL7) data. Displaying both types of data on the screen simultaneously might trouble a risk officer.
Performance and scalability: The SLA for typical X12 HIPAA transactions is different than that required for HL7 documents that include FIFO message sequence processing. Having separate domains for these two transaction sets enhances performance and achieves SLAs.
Additionally, if an enterprise is already using a domain for their B2B transactions, it should not upgrade that domain for use as healthcare domain for HL7 transactions too. Instead the enterprise should create an separate domain for HL7 transactions.
The single exception to this policy is the case where the enterprise dumps both X12 HIPAA and HL7 documentation in the database. For example, when adding and/or updating HL7 and X12 HIPAA docs in an EPDR (enterprise patient data repository).
Figure H-1 shows an example SOA healthcare topology that demonstrates the use of separate domains for B2B and Healthcare. The load balancer uses HTTP to route B2B transactions to the B2B domain and uses TCP to route Healthcare transactions to the Healthcare domain.