EHR-IIS Interoperability Enhancement Project 

Transport Layer Protocol Recommendation 

Transport Layer Expert Panel 

EHR-IIS Interoperability Enhancement Project 

Immunization Information Systems Support Branch (IISSB)

National Center for Immunization and Respiratory Disease (NCIRD) 

Centers for Disease Control and Prevention (CDC) 

May 2011 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 2  

Table of Contents 

Acknowledgements....................................................................................................................................4

Executive Summary...................................................................................................................................6

1. Project Background......................................................................................................................... 8

1.1. Meaningful Use and the Need for Enhanced Interoperability ...................................... 8

2. Purpose...............................................................................................................................................9

3. Transport Layer Expert Panel....................................................................................................... 9

3.1. Intended Audience................................................................................................................. 10

3.2. Intended Usage....................................................................................................................... 10

3.3. Approach..................................................................................................................................10

3.4. Mission/Goal............................................................................................................................ 14

3.5. Objectives ................................................................................................................................15

3.6.    Scope.........................................................................................................................................15

4. Summary of Alternative Transport Protocols Evaluated..................................................... 16

4.1.    ebXML .......................................................................................................................................16

4.2. SMTP+S/MIME......................................................................................................................... 17

4.3. HTTPS POST/REST................................................................................................................ 18

4.4.    SOAP .........................................................................................................................................19

5. Recommendation of SOAP Transport Layer Protocol......................................................... 20

5.1. Process of Selection ............................................................................................................. 20

5.2. Justification of SOAP Selection......................................................................................... 21

6. Acknowledgement of Other Transport Protocols ................................................................. 22

7.    Impacts .............................................................................................................................................25

7.1. IIS Program Impacts.............................................................................................................. 25

7.2. EHR Vendor Impacts ............................................................................................................. 26

7.3. Provider Impacts .................................................................................................................... 27

8. Conclusions.....................................................................................................................................27
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 3  

Appendices................................................................................................................................................29

Appendix A: Subject Matter Experts...................................................................................................... 30

Appendix B: Protocol Research Workgroups ...................................................................................... 35

Appendix C: Business Requirements.................................................................................................... 36

Appendix D: Use Cases .......................................................................................................................... 39

Appendix E: Comparison by Defined Business Requirements......................................................... 41

Appendix F: Known Global Issues......................................................................................................... 69

Appendix G: Technology Recommendation Development Workgroups ......................................... 71

Appendix H: Definitions........................................................................................................................... 73

Appendix I: Related Background Reading Materials .......................................................................... 74
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 4  

Acknowledgements 

Members of the EHR-IIS Interoperability Enhancement Project appreciate and 

acknowledge the following subject matter experts (SMEs) who contributed their time 

and expertise to the evaluation of technologies and documentation review which were 

critical for the completion of this document and the project. Detailed information 

regarding the panel members’ current appointments, areas of expertise and contact 

information can be found in Appendix A. 

• Angel Aponte, New York Citywide Immunization Registry (CIR) 

• Bob Barker, Electronic Health Record Association (EHRA) 

• Michael Berry, HLN Consulting, LLC / Rhode Island KIDSNET 

• Nathan Bunker, Dandelion Software & Research, LLC / ImmTrac (TX) 

• Marcelo Caldas, CDC Public Health Informatics and Technology Program Office 

(PHITPO) 

• Concetto “Frank” Caniglia, American Immunization Registry Association 

(AIRA) 

• George Cole, Allscripts / Electronic Health Record Association (EHRA) 

• Emily Emerson, Minnesota Immunization Information Connection (MIIC) 

• Josh Friedman, Hewlett Packard (HP) 

• Paul Groll, Michigan Care Improvement Registry (MCIR) 

• Gautam Kesarinath, CDC Public Health Informatics and Technology Program 

Office (PHITPO) 

• Thomas Maerz, Wisconsin Immunization Registry (WIR) 

• Arien Malec, NHIN Direct 

• Ben Martinez, New Mexico Statewide Immunization Information System 

(NMSIIS) 

• Deborah Rochat, Oregon ALERT IIS 

• David Rose, Scientific Technologies Corporation (STC) / Washington CHILD 

Profile Immunization Registry 

• Purvesh Shah, NextGen Healthcare 

• Shane Speciale, Avanza Systems Inc. / South Dakota Immunization Information 

System 

• Cecile Town, Indian Health Service (IHS) 

We would also like to acknowledge the external reviewers of the recommendation 

document for their willingness to read and constructively critique the workgroup’s 

materials. Their efforts ensured that the information detailed in this document is clear, 

thorough, and useful to various stakeholder audiences. 

• Noam Arzt, HLN Consulting, LLC 

• Lori Ashford, ImmTrac (TX) 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 5  

• Tammy Clark, Mississippi Immunization Information Exchange (MIIX) 

• Scott Danos, Orion Health 

• Tim Elsbrock, New Mexico Statewide Immunization Information System 

(NMSIIS) 

• Bon Franklin, Arizona State Immunization Information System (ACIIS) 

• Joel Freborg, North Dakota Immunization Information System (NDIIS) 

• Phyllis Gervais-Voss, Wyoming Immunization Registry (WyIR) 

• Robert Grenwelge, Wyoming Immunization Registry (WyIR) 

• Spence Heron, DC Immunization Registry System 

• Savonya Jones, Mississippi Immunization Information Exchange (MIIX) 

• Rick Joslin, Wyoming Immunization Registry (WyIR) 

• Dave Kaiser, Hewlett Packard (HP) 

• Ken Larsen, HLN Consulting, LLC 

• Peter Lemmon, Oklahoma State Immunization Information System (OSIIS) 

• Christie Levy, Mississippi Immunization Information Exchange (MIIX) 

• Eric Lindskog, Mayo Clinic 

• Nancy McConnell, Utah Statewide Immunization Information System (USIIS) 

• Christopher Qualls, Mississippi Immunization Information Exchange (MIIX) 

• Priya Rajamani, Minnesota Immunization Information Connection (MIIC) 

• Tim Stolldorf, Epic Systems Corporation 

• Bill Vertrees, Colorado Immunization Information System (CIIS) 

• Gordon Zeis, Office of the Health Commissioner and Deputy Mayor for Health 

and Opportunity, Philadelphia Department of Public Health 

• Deven Zipp, CHILD Profile Immunization Registry (WA) 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 6  

Executive Summary 

The American Reinvestment & Recovery Act (ARRA) includes many measures to 

modernize infrastructure. The Health Information Technology for Economic and Clinical 

Health (HITECH) Act is a measure which supports the concept of Electronic Health 

Records - Meaningful Use [EHR-MU]. HITECH proposes the meaningful use of 

interoperable electronic health records throughout the U.S. healthcare delivery system 

as a critical national goal and awards funds to time-limited projects which demonstrate 

innovative approaches that enhance this interoperability, including an effort to promote 

EHR and Immunization Information Systems (EHR-IIS) interoperability. Immunization 

Information Systems (IIS) are confidential, population-based, computerized information 

systems that attempt to collect vaccination data within a geographic area. IIS are an 

important tool to increase and sustain high vaccination coverage by consolidating 

vaccination records from multiple providers, generating reminder and recall vaccination 

notices, and providing official vaccination forms and vaccination coverage assessments. 

To facilitate the development and implementation of EHR-IIS integration enhancement, 

the Centers for Disease Control & Prevention (CDC) Immunization Information System 

Support Branch (IISSB) focused on the recommendation of a transport layer protocol 

and supporting documentation to address the issue of utilization of multiple transport 

layer protocols across grantee programs and vendors and the limitations in real-time 

message transmission. 

The CDC established a panel of subject matter experts and external reviewers, 

consisting of industry experts, to evaluate and analyze currently utilized industry 

transport protocols and recommend the most suitable option for EHR-IIS 

interoperability. It was the vision of this panel to recommend technologies to further 

promote health system interoperability. Based on research with funded project grantees, 

the protocols identified for consideration included the following: 

• ebXML (PHINMS) 

• SMTP+S/MIME (Direct Project) 

• SFTP 

• HTTPS POST/REST 

• SOAP 

An initial meeting and subsequent sessions over eight weeks involved the discussion 

and formulation of the mission, scope, approach, definitions, business requirements, 

and use cases for the project as well as detailed research on each transport layer 

protocol. During a three-day, in-person session, the panel SMEs were provided with a 

project overview and detailed feedback on each transport layer protocol option. Panel 

members identified SOAP as the best choice to meet the current and future needs of IIS 

data exchange, with the best chance for broad adoption across disparate healthcare 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 7  

systems. In addition, SOAP was recommended for a variety of reasons including, but 

not limited to: 

• SOAP supports synchronous real-time vaccination update and query/response. 

• SOAP has a natural look and feel for developers on both the sender and receiver 

side. 

• SOAP has a machine-readable contract that allows for a clear interface across all 

healthcare systems. 

With the panel’s recommendation of SOAP came the acknowledgment of the role and 

value of other transport layer options as well as the expectation that IIS would continue 

to use other transport layer technologies currently in place. IISSB supports the effort to 

recommend a standard transport option that our grantee cities and states as well as 

other healthcare systems would support for immunization interoperability. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 8  

1. Project Background 

Immunization Information Systems (IIS) are confidential, population-based, 

computerized information systems that attempt to collect vaccination data 

concerning all covered populations within a geographic area. IIS are an important 

tool to increase and sustain high vaccination coverage by consolidating vaccination 

records from multiple providers, generating reminder and recall vaccination notices, 

and providing official vaccination forms and vaccination coverage assessments. 

1.1. Meaningful Use and the Need for Enhanced Interoperability 

The American Reinvestment & Recovery Act (ARRA) includes many measures to 

modernize our nation's infrastructure. In particular, the "Health Information 

Technology for Economic and Clinical Health (HITECH) Act" is one such 

measure which supports the concept of Electronic Health Records - "Meaningful 

Use" [EHR-MU], an effort led by Centers for Medicare & Medicaid Services 

(CMS) and the Office of the National Coordinator (ONC) for Health IT. HITECH 

proposes the "meaningful use" of interoperable electronic health records 

throughout the U.S. healthcare delivery system as a critical national goal. There 

are federal financial incentives designed to spur healthcare organizations toward 

meeting meaningful use standards for electronic health records. 

Funds have been awarded to the following seventeen states and three city 

immunization program grantees through a competitive process for a two-year 

CDC cooperative agreement for conducting time-limited projects. This 

demonstrates how innovative approaches can successfully and measurably 

enhance the interoperability of electronic immunization data exchange between 

EHR systems and IIS. 

• Arizona 

• Colorado 

• District of Columbia 

• Idaho 

• Michigan 

• Minnesota 

• Mississippi 

• Montana 

• New Mexico 

• New York City 

• North Dakota 

• Oregon 

• Philadelphia 

• Rhode Island 

• South Dakota 

• Texas 

• Utah 

• Washington 

• Wisconsin 

• Wyoming
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 9  

2. Purpose 

The purpose of this EHR-IIS Interoperability Enhancement Project is to provide 

support for the enhanced interoperability of EHRs with IIS, specifically focusing on 

the exchange of vaccination records and reduction of the burden of duplicate data 

entry for providers. The project will also obtain technical and operational information 

and provide guidance to HITECH Act grantees for the Immunization Information 

Services Support Branch (IISSB). This project will produce documents on new 

guidance, refine/modify existing guidance, and develop necessary materials for 

enhancing EHR-IIS interoperability. 

A recommended transport protocol allows the vendor focus to be on clinical 

functionality, as opposed to resources spent on supporting multiple transports. A 

transport protocol recommendation should allow for cost savings to the stakeholder 

practices as a result of an interoperable solution that works across all participating 

registries. 

The project focuses on three separate and independent technological components 

related to enhancing interoperability: Transport Layer/Technical Interoperability; HL7 

2.5.1 Messaging/Semantic Interoperability; and Client De-Duplication. Each 

component is assigned to a dedicated expert panel as a distinct segment to address 

in greater detail. 

3. Transport Layer Expert Panel 

The Transport Layer panel addressed the problem of technical complexity caused by 

the utilization of multiple transport layer protocols across grantee programs and 

vendors and the limitations in real-time message transmission. The goal of the panel 

was to recommend a transport layer protocol and supporting documentation for the 

immunization industry to move toward as well as technical support and guidance 

documentation to facilitate the eventual utilization of the recommended transport 

layer by the immunization community. The Transport Layer provides electronic 

transmission and receipt of health data from one system to another and is 

independent of the message itself. In addition to its use by all grantees, the 

recommended protocol can be utilized by all IIS, EHRs, HIEs, and other healthcare 

system community members. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 10  

3.1. Intended Audience 

Artifacts produced by the Transport Layer Panel were designed to be read by 

programmatic, technical, and operational experts who are involved in creating or 

maintaining an IIS, HIE, EHR or other health system. The intent of the document 

was to bridge the gap between technical and program staff to facilitate a mutual 

understanding of the importance of a standard transport layer protocol and 

target actions to address these recommendations. 

3.2. Intended Usage 

The Transport Layer Panel’s recommendation document is a collection of expert 

best practice recommendations. It provides technical and operational 

consultation and guidance for entities choosing to implement these 

recommendations. It is a means of advocacy and feedback for the community. 

The Transport Layer Panel’s recommendation document encourages IIS to 

employ any or all of the project implementation specifications once they are 

finalized. Guidance and consultation will be provided to those grantees that 

choose to implement these recommendations. 

The document does not establish technological mandates or requirements. It will 

not provide hands-on execution of data clean-up or other technical activities. 

Grantees are not dependent on the recommendations found in the panel 

document and are encouraged to continue moving forward with their current 

implementation plans, if necessary. However, the protocol mentioned herein 

may help build for flexibility. 

3.3. Approach 

Initial preparatory off-line work, including assembly of pertinent materials, 

production of preparatory notes, analysis of current transport layer protocols, and 

development of preliminary approach documentation, was performed by the 

project team (Appendix I). IIS Fact Sheets were obtained from the 20 project 

grantees to evaluate and determine transport protocols for evaluation and next 

steps. There were 5 overlapping transport methods: ebXML (PHINMS), 

SMTP+S/MIME (Direct Project), SFTP, HTTPS and SOAP. 

The CDC IISSB extended invitations and formed a panel consisting of subject 

matter experts (SMEs) and external reviewers representing industry experts from 

the following groups/organizations. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 11  

• 16 of the 20 funded project grantees 

• ONC (Office of the National Coordinator for Health Information Technology) 

• CDC Public Health Informatics and Technology Program Office (PHITPO) 

• AIRA (American Immunization Registry Association)

o Comprised of 50 members representing state, regional, and local IIS 

Programs; IIS Vendors; IIS consultants; and reciprocal partners. 

• EHRA (Electronic Health Record Association)

o Comprised of 45 EHR vendors from across the nation. 

o Includes 90% of the installed electronic health records and health 

information systems in the nation. 

• IHS (Indian Health Service)

o Uses RPMS (Resource and Patient Management System) to track 

immunizations in 34 states. 

o Supports interoperability with a number of IIS. 

• IIS vendors (Immunization Information System) and platform providers 

o Involved 4 IIS vendors supporting 31 IIS. 

• EHR vendors 

There was a panel kick-off meeting to discuss a detailed understanding of the 

mission, scope and approach for the project and the specific roles of SMEs and 

external reviewers. The panel was also given an electronic “packet” of 

background reading materials following the session. 

The SMEs met in two facilitated sessions to agree upon panel mission, 

objectives, scope, definitions (Appendix H) and 20 business requirements. 

The SMEs were divided into workgroups, each focusing their efforts on the 

evaluation of a different protocol (Appendix B). In creating the workgroup 

assignments, the project team sought to strike a balance on each workgroup of 

those with a deep expertise and knowledge of the particular transport protocol as 

well as those new to the protocol. This was done to foster discussion and explore 

all possible scenarios. 

The SME workgroups evaluated and compared transport options against the 20 

business requirements (Appendix C). Each workgroup created a summary of its 

assigned transport layer option and an analysis of each option against those 

business requirements (Appendix E). The following table is a summary of their 

findings. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 12  

Subject Area SOAP HTTPS POST/REST The Direct Project 

/SMTP+S/MIME 

PHINMS/ebXML 

General Solution Requirements 

Payload Size No Limitations Often limited by 

gateways No limitations 

Synchronous 

Response No Limitations Does not support 

With client install, true 

end-to-end (EHR -> 

IIS) synchronous 

transactions difficult 

Asynchronous 

Response No limitations or differences 

Technology Neutral No limitations or differences 

Technology 

Credibility 

IIS usage; 

very active in 

EHRs; WSDL 

providing 

machine 

readable 

contract 

HTTPS POST 

VXU/VXQ use cases 

implemented in 

numerous states 

since 2002 

Growth in healthcare; 

minimal EHR/IIS use; not 

best for Meaningful Use 

Stage 3 and immediate 

query/response use 

cases 

Few IIS 

implementations; no 

known new 

installations; native 

EHR interface difficult 

Secure 

Transmission 

Secure transmission provided by TLS Secure transmission 

through S/MIME; SMTP 

header not encrypted 

Secure transmission 

by TLS 

Reliable 

Transmission 

WS-Reliable 

Messaging 

protocol 

No differences or advantages 

Authentication Authentication and trust models of relatively equal effort 

IIS or Receiver Requirements 

Ease of 

Implementation 

Slightly more 

complex than 

HTTPS 

Shortest 

implementation 

timeframe 

Significant IIS learning 

curve 

Lengthy initial 

implementations 

Ease of 

Maintenance No differences or advantages 

Scalable No limitations or differences 

Ease of Use No differences or advantages
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 13  

Performance No differences or advantages

Cost Effective No differences or advantages 

Sender Requirements 

Ease of 

Implementation No differences or advantages

Ease of 

Maintenance No differences or advantages

Scalable No limitations or differences 

Ease of Use No differences or advantages

Performance No differences or advantages

Cost Effective No differences or advantages

The workgroups also evaluated their assigned transport protocol against the HL7 

2.5.1 Use Cases (Appendix D): 

1) Send Immunization History 

2) Receive Immunization History 

3) Request Immunization History 

4) Return Immunization History 

4a) Find Candidate Clients 

5) Accept Requested History 

6) Send Demographic Data 

7) Accept Demographic Data 

8) Acknowledge Receipt 

9) Report Error 

In this comparison, the panel acknowledged that all use cases could be met. 

The lone exception was a constraint by the CDC HL7 Implementation Guide on 

“Request Immunization History” and “Return Immunization History” use cases 

commonly referred to as “Query/Response”. The constraint dictates that the 

“Query/Response” loop be “immediate” or synchronous. Both the Direct Project 

and PHINMS (in certain settings) do not provide the possibility for the exchange 

to be synchronous.

Several known global issues were identified by the workgroup (Appendix F). 

During these workgroup sessions, it was apparent that the global issues 

identified were present in all protocols, and thus were not useful in comparison. 

Additional global issues continued to be identified throughout the analysis 

process. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 14  

A three-day, in-person session with the Transport Layer Expert Panel for the 

EHR-IIS Interoperability Project was held March 8-10, 2011 in Atlanta, Georgia. 

The SMEs were divided into subgroups related to their protocol to generate the 

contents of this document, as well as appendices (Appendix G). 

Relatively rigorous conditions for inclusion of a recommendation in the best 

practice guidelines were used and received approval by every expert. Room for 

inevitable disagreements in minor details and preferences among experts was 

provided by implementing the following definition of consensus: “I can live with 

that and support it.” The first part of this definition (“I can live with that”) allowed 

the group to focus on achieving a consensus in principle, avoiding prolonged 

discussions on minor features (e.g., “at least no one disagrees strongly enough 

to veto the agreement”). The second part (“I support it”) provided a due diligence 

check to ensure that there were no serious disagreements left among the experts 

and assurance that they agreed enough with the recommendation to stand 

behind it and support it. 

The external reviewers held a preliminary meeting to review findings and held 

additional individual meetings to clarify feedback as required. External reviews 

provided iterative review and input into the creation of a Transport Layer 

Technology Recommendation Document. This group will also provide ongoing 

implementation guidance that will support project grantees choosing to 

implement the recommended transport protocol. 

 

3.4. Mission/Goal 

The Transport Layer Expert Panel is comprised of key stakeholders focused on 

recommending a unified technical interoperability framework for immunizationrelated transport that allows for both broad adoption and long-term viability as an 

industry standard. 

The recommendation will identify and support the transport protocols necessary 

for electronically sharing immunization information among the stakeholders. It is 

the vision of this panel to recommend technologies to further promote health 

system interoperability. 

It is the goal of the Transport Layer Expert Panel to enhance interoperability of 

electronic immunization data exchange between healthcare systems and 

Immunization Information Systems (IIS) through the recommendation of a 

standardized transport layer protocol. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 15  

3.5. Objectives 

The Transport Layer Expert Panel will recommend a transport methodology for 

health care system-to-health care system HL7 immunization messaging 

interoperability for long-term and broadest adoption with a focus on providers 

and future potential meaningful use phases. The panel will create a 

recommendation document detailing the results of their analysis, identifying the 

recommended transport methodology and acknowledging the usage of 

alternative transport methods. The panel will also create an implementation Wiki 

based upon the recommended transport methodology that will provide technical 

guidance to grantees. 

It should be noted that while the transport layer is message agnostic, the panel 

focused on HL7 V2 messages presently used in the IIS setting. 

3.6. Scope 

In recommending a transport methodology, the expert panel took into 

consideration and addressed the following topics: 

• Payload size 

• Synchronous and asynchronous messaging 

• Secure transmission of the message 

• Authentication between the sender and the receiver 

• Sustainability of the transport methodology 

• Performance 

• Reliable message transmission 

• Ease of implementation 

• Use cases which include both Unsolicited Vaccination Updates (VXU) and 

queries (VXQ, QBP) from one health system to another health system 

Out of Scope issues included the following: 

• Other public healthcare systems such as vital records, Medicaid, and chronic 

disease reporting 

• Authorization following authentication. Authorization can occur in numerous 

different ways and is foundationally specific to the IIS itself and not transport 

• Hands-on execution of data clean-up or other program technical activities 

• Interface or data quality certification 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 16  

                                                           

4. Summary of Alternative Transport Protocols Evaluated 

The SFTP transport protocol was eliminated from consideration early in the process 

because it failed to fully meet many identified business requirements. 

As a result, the four technologies under consideration by the expert panel were: 

• ebXML 

• SMTP+S/MIME 

• HTTPS POST/REST 

• SOAP 

4.1. ebXML

Wikipedia defines ebXML as follows: 

Electronic Business using eXtensible Markup Language, 

commonly known as e-business XML, or ebXML as it is 

typically referred to, is a family of XML based standards 

sponsored by OASIS (Organization for the Advancement 

of Structured Information Standards) and UN/CEFACT 

(United Nations Centre for Trade Facilitation and Electronic 

Business). Their mission is to provide an open, XML-based 

infrastructure that enables the global use of electronic 

business information in an interoperable, secure, and 

consistent manner by all trading partners.1

Developed by the CDC, the Public Health Information Network Messaging 

System (PHINMS) uses the ebXML infrastructure to securely transmit public 

health information over the Internet. PHINMS is a generic, standards-based, 

interoperable and extensible message transport system that is platformindependent and loosely coupled with systems that produce outgoing messages 

or consume incoming messages. 

It was the intent of the panel to evaluate the ebXML protocol standard and not 

the PHINMS product (an implementation of ebXML). The panel acknowledged 

to date, EHR–IIS transport over ebXML is exclusively through PHINMS. Further, 

the panel’s experience with ebXML was directly related to PHINMS’ 

implementation of ebXML, PHINMS usage, and the historical knowledge of 

PHINMS. Thus, ebXML was evaluated in the context of PHINMS. 

1 ebXML – Wikipedia http://en.wikipedia.org/wiki/EbXML (Nov. 15, 2010)
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 17  

                                                           

4.2. SMTP+S/MIME 

Wikipedia provides the following definitions for SMTP + S/MIME. 

Simple Mail Transfer Protocol (SMTP) is an Internet standard for 

electronic mail (e-mail) transmission across Internet Protocol (IP) 

networks. SMTP was first defined by RFC 821 (1982, eventually 

declared STD 10), and last updated by RFC 5321 (2008) which 

includes the extended SMTP (ESMTP) additions, and is the 

protocol widely used today. SMTP is specified for outgoing mail 

 transport and uses TCP port 25. The protocol for new submissions 

is effectively the same as SMTP, but it uses port 587 instead. 

While electronic mail servers and other mail transfer agents use 

SMTP to send and receive mail messages, user-level client mail 

applications typically only use SMTP for sending messages to a 

mail server for relaying. For receiving messages, client applications 

usually use either the POST Office Protocol (POP) or the Internet 

Message Access Protocol (IMAP) or a proprietary system (such 

as Microsoft Exchange or Lotus Notes/Domino) to access their 

mailbox accounts on a mail server.2

S/MIME (Secure/Multipurpose Internet Mail Extensions) is a 

standard for public key encryption and signing of MIME data. 

S/MIME is on an IETF standards track and defined in a number 

of documents, most importantly RFCs. S/MIME was originally 

developed by RSA Data Security Inc. The original specification 

used the recently developed IETF MIME specification with the 

de facto industry standard PKCS#7 secure message format. 

Change control to S/MIME has since been vested in the IETF, 

and the specification is now layered on Cryptographic Message 

Syntax, an IETF specification that is identical in most respects 

with PKCS #7. S/MIME functionality is built into the majority 

of modern e-mail software and interoperates between them.3

The only implementation of SMTP+S/MIME in the IIS community is via the 

National Health Information Network (NHIN) Direct Project-specified 

transport protocol. 

2 Simple Mail Transfer Protocol – Wikipedia http://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol (Feb. 8, 2011)

3 S/MIME – Wikipedia http://en.wikipedia.org/wiki/S/MIME (Feb. 8, 2011)
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 18  

                                                           

4.3. HTTPS POST/REST 

In a review of data exchange technologies, the American Immunization Registry 

Association defined the HTTPS POST protocol as follows: 

The POST method is commonly used to submit form data from 

web browsers. The IIS implementation of HTTP/POST uses the 

same approach for transporting data that is used to transport data 

from a web page form, but uses specific data fields that are 

defined for authentication information and the HL7 payload. The 

IIS responds with a single character string comprised of the HL7 

message, for example – an ACK response that acknowledges 

receipt of the message.4

Wikipedia provides the following conceptualization of the REST architecture: 

REST (Representational State Transfer)-style architectures consist 

 of clients and servers. Clients initiate requests to servers; servers 

process requests and return appropriate responses. Requests and 

responses are built around the transfer of representations of 

resources. A resource can be essentially any coherent and 

meaningful concept that may be addressed. A representation 

of a resource is typically a document that captures the current or 

intended state of a resource. 

At any particular time, a client can either be in transition between 

application states or "at rest". A client in a rest state is able to 

interact with its user, but creates no load and consumes no perclient storage on the set of servers or on the network. 

The client begins sending requests when it is ready to make the 

transition to a new state. While one or more requests are outstanding, 

the client is considered to be in transition. The representation of 

each application state contains links that may be used the next 

time the client chooses to initiate a new state transition. 

RESTful architectures of HTTPS can be based on other Application 

Layer protocols if they already provide a rich and uniform vocabulary 

for applications based on the transfer of meaningful representational 

state. RESTful applications maximize the use of the pre-existing, 

well-defined interface and other built-in capabilities provided by the 

4

 AIRA, Evaluating Data Exchange Technologies for Communicating with IIS

http://www.immregistries.org/pdf/AIRA_IIS_TransportLayer_Review.pdf (Nov. 3, 2010)
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 19  

                                                           

chosen network protocol, and minimize the addition of new 

application-specific features on top of it.5

4.4. SOAP 

Wikipedia’s definition of the SOAP protocol is as follows: 

SOAP, originally defined as Simple Object Access Protocol, is 

a protocol specification for exchanging structured information 

in the implementation of web services in computer networks. 

It relies on Extensible Markup Language (XML) for its message 

format, and usually relies on other application layer protocols, 

most notably Remote Procedure Call (RPC) and Hypertext 

Transfer Protocol (HTTP), for message negotiation and 

transmission. SOAP can form the foundation layer of a web 

services protocol stack, providing a basic messaging framework 

upon which web services can be built. 

This XML-based protocol consists of three parts: an envelope, 

which defines what is in the message and how to process it; a 

set of encoding rules for expressing instances of applicationdefined data types; and a convention for representing procedure 

calls and responses. 

A simple example of how SOAP procedures can be used is as 

follows: 

A SOAP message could be sent to a web-service-enabled 

website (for example, a real estate price database) with the 

parameters needed for a search. The site would then return 

an XML-formatted document with the resulting data (e.g., 

prices, location, features). Because the data is returned in 

a standardized, machine-parseable format, it could then be 

integrated directly into a third-party website or application.6

5

 Representational State Transfer – Wikipedia http://en.wikipedia.org/wiki/REST (Nov. 3, 2010)

6 SOAP – Wikipedia http://en.wikipedia.org/wiki/SOAP (Nov. 3, 2010)
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 20  

5. Recommendation of SOAP Transport Layer Protocol 

5.1. Process of Selection 

During the three-day session, a presentation by and for panel SMEs provided a 

project overview and detailed feedback on each transport layer protocol option 

and the additional known global issues. 

A selected panelist from each transport workgroup led a discussion summarizing 

the findings of the workgroup for each option. 

After the four protocol discussions were complete, the panel was assessed to 

determine if an early consensus could be attained. Although there was no early 

consensus, the panel was able to eliminate SMTP+S/MIME and ebXML from 

further consideration as a protocol recommendation, further narrowing the 

transport layer options down to two: SOAP and HTTPS. 

SMTP+S/MIME did not meet the EHR-IIS current use cases or long-term goals 

as well as the other protocols. Particularly, it did not allow for synchronous 

communication and did not support the following three HL7 use cases: 

• Request Immunization History From Another System 

• Find Candidate Clients From Another System and Select One to Be Used 

When Requesting An Immunization History 

• Accept Requested Immunization History In Response to a Query for an 

Immunization History From Another System 

The NHIN Direct-specified protocol will still be supported as a valid strategy for 

certain scenarios, but the other transports have a better chance of broad 

adoption with synchronous data updates and query/response, both required in 

the EHR and IIS community and consistent with the panel’s mission for a longterm solution (Please see Section 6 for more details). 

ebXML was identified as highly complex and as having too much product 

reliance upon PHINMS. Concerns regarding the future and long-term viability of 

this protocol were also discussed. Also, PHINMS, as it is configured, does not 

allow for synchronous communication. Similar to SMTP, ebXML does work as a 

transport layer, and the panel acknowledged that those currently utilizing these 

technologies should not discontinue doing so (Please see Section 6 for more 

details). 

The two remaining transport options, HTTPS and SOAP, were revisited. This 

included the evaluation of both sets of business requirements and discussion of 

only the differences between HTTPS and SOAP. The following business 

requirements comparisons were made: 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 21  

• Protocol Credibility 

o HTTPS for VXQ and VXU has been implemented in numerous states 

since 2002. 

o SOAP has only a few known live implementations, but numerous 

states working towards an implementation. 

o SOAP provides a machine-readable contract at the interface level 

(WSDL). 

• Ease of Implementation (Sender and Receiver) 

o It is slightly quicker to implement HTTPS. 

• Reliable Transmission 

o While not used in current implementations, SOAP has the WSReliable Messaging specification, which could be implemented if 

necessary. 

During these discussions, very minor differences were identified between the 

two protocols, and it was noted that success could be found through either 

option. 

The vote on the remaining two protocols determined the SOAP Web Service to 

be the recommended transport protocol for electronically sharing immunization 

information. This was the result of the overall expectation of the panel members 

that SOAP would allow for the broadest EHR adoption. Forty known EHRs and 

nine known IIS currently support SOAP-based transport. The protocol also is 

officially supported by the organizations, Integrating the Healthcare Enterprise 

(IHE) and the Electronic Health Records Association (EHRA). 

The results of the vote included 13 panel members recommending SOAP, 3 

members recommending HTTPS, and 2 members abstaining. All 5 panel 

members who did not vote for SOAP indicated that they could live with and 

support SOAP as the panel’s recommendation. The panel used the previously 

implemented definition of a consensus (“I can live with that and support it”) 

among subject matter experts (SMEs) regarding the recommendation. 

The determining factors leading to the selection of SOAP as the preferred 

standard protocol by the expert panel are detailed in the following section. 

5.2. Justification of SOAP Selection 

The SOAP protocol performed well when analyzed for the use cases and 

business requirements identified by the panel. 

Members concluded that SOAP would meet not only the current needs of IIS 

data exchange, but also stand strong in the future. In summary, SOAP was 

selected for a variety of reasons. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 22  

• SOAP had the best chance for broad adoption across disparate healthcare 

systems. While nearly impossible to measure, the best chance at broad 

adoption is a key factor in the success of any technology decision and even 

more important when considering an interoperability project. The panel 

addressed this by looking at key stakeholders, prior implementations, and 

industry trends. With numerous EHRs supporting SOAP efforts today, the 

inclusion of SOAP transports in the IHE XDS.b profile, and several IIS 

supporting or moving to SOAP, the panel determined there was the broad 

community adoption necessary to support the choice of SOAP. 

• It is widely used by the EHR community. The 2011 Integrating the Healthcare 

Enterprise (IHE) Connectathon included 40 EHRs which support the SOAPbased IHE XDS.b profile. 

• SOAP has a natural language specific syntax for developers on both the 

sender and receiver side. From a development standpoint, multiple SOAP 

development and support toolkits exist ranging from open source to privately 

licensed software along with a large community of practice, web resources, 

tutorials and example code which freely exist to make ease of use very 

attractive. 

• SOAP has a machine-readable contract between sender and receiver to 

describe its conventions (such as how and where to specify authentication 

credentials) that allows for a clear interface across all healthcare systems. 

• Several IIS are either live with a SOAP service or working towards a SOAP 

service. For example, New York City, one of the 20 grantees represented on 

this panel, has a live SOAP Web Service. 

• Expert panel creation of a common Web Service Definition Language (WSDL) 

will allow for easier EHR adoption. 

• As HL7 immunization messaging moves towards HL7 version 3, with XMLbased HL7 messages, SOAP has the ability to transport streams of text as 

well as object models. 

6. Acknowledgement of Other Transport Protocols 

While the panel recommended SOAP, it acknowledged the role and value of other 

transport layer options. It is not the expectation of the panel that registries 

discontinue the usage of other transport layer technologies currently in place or not 

implement technologies necessary to meet specific scenarios requiring something 

other than SOAP. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 23  

                                                           

ebXML 

PHINMS is already used in several states for immunization-related messaging, 

supporting millions of transactions annually. It has a proven, successful, and flexible 

health system-to-health system history of implementation supported by standards. 

The panel’s recommendation of SOAP should not be interpreted as a statement of 

lack of support for ebXML by CDC or this expert panel. ebXML will continue to be 

supported by CDC for immunization registries and other public health organizations. 

SMTP+S/MIME 

As specified by the Direct Project, SMTP+S/MIME provides interoperable universal 

addressing and transport for directed information exchange between known 

recipients. Because the desired scope for transport focused on query/retrieve as well 

as directed exchange, the Direct Project specifications were not appropriate for the 

entire needs within the panel’s scope. However, the transport workgroup 

encouraged IIS utilization of Direct when appropriate. Such uses could include 

submission of VXU HL7 messages as an interim strategy, copies of 

submitted immunization data from EHRs to consumers, pushed notifications to 

EHRs of missing immunizations, and other scenarios where a pushed message is 

appropriate. 

HTTPS 

HTTPS POST has been widely used by the IIS community over the past several 

years and was comparable to SOAP in many of the evaluation categories 

considered by the panel, since SOAP transactions typically use HTTPS POST as 

the underlying protocol. In 2002, the HL7 Immunization Registry Task Force 

subgroup on HTTP message transport published “Transport of Immunization HL7 

transactions over the Internet Using Secure HTTP7

,” and many registries adopted 

the conventions in that document, adding a degree of standardization to the use of 

HTTPS POST for IIS HL7 interfaces. Because the implementation guides for HL7 

immunization messaging call for the HL7 messages to be sent intact as streams of 

text, the simplicity of HTTPS POST has been a good match for its relatively simple 

payload. 

The use of raw HTTPS POST – while conceptually simple compared to higher-level 

protocols – is dissimilar from the SOAP-based services common to the EHR 

7 Transport of Immunization HL7 transactions over the Internet Using Secure HTTP 

 http://www.immunizeusa.org/attachments/wysiwyg/1/HL7_Secure_Transport_Ver1-0Sept02.pdf (Sept. 17, 2002)
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 24  

industry, as well as the emerging REST-based services common to many other webbased vendors. Unlike SOAP, HTTPS POST lacks a machine-readable contract 

between sender and receiver to describe its conventions (such as how and where to 

specify authentication credentials). 

The panel’s subgroup on HTTPS POST also evaluated REST. However the lack of 

any current immunization messaging implementation in REST was seen as a 

disadvantage. Finally, as HL7 immunization messaging moves towards HL7 version 

3, with XML-based HL7 messages, SOAP – with its ability to transport not just a 

stream of text but an object model – may be more appropriate for IIS messaging of 

the future. 

It is the expectation of the expert panel that registries and their trading partners that 

use HTTPS POST for HL7 v2.x will continue to do so even as they add support for 

SOAP. 

SFTP 

SFTP is widely available for a number of platforms and provides acceptable 

functionality for many users. While the panel did not move forward with an 

evaluation of SFTP, that should not imply a lack of its use and value in the 

appropriate setting. SFTP continues to see heavy use in the IIS community 

including but not limited to vital records feeds, Medicaid feeds, Women Infants and 

Children (WIC) extracts, and data migration projects. Many registries in other health 

systems such as infectious disease and cancer reporting rely on SFTP for 

transmittal of electronic data in other public health arenas. 

The panel did not determine that SFTP is not acceptable; however other options 

identified were better suited for this project. Some of the reasons that were cited by 

panel members include the following: 

• The SFTP protocol was not proven to be scalable for real-time 

transactions/responses. 

• The SFTP protocol was not synchronous; it is appropriate for old interfaces but 

not a good choice for a national standard. 

• SFTP could have a significant overhead for establishing authentication for all 

providers. 

• SFTP will not support real-time reporting. The protocol is not forward-looking; it is 

difficult to use to meet real-time requirements. 

• SFTP is not robust enough to fulfill all of the requirements. 

• SFTP is hard to integrate into EHRs and workflow. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 25  

7. Impacts 

The recommendation of SOAP Web Services has a number of effects on the 

Immunization Information System (IIS) and Electronic Health Record (EHR) 

communities. The Transport Layer Workgroup will create an implementation Wiki 

that defines the standard Web Service interface. Following this, there are a number 

of activities that immunization registries will need to work on, in order to gain benefits 

from these services. 

7.1. IIS Program Impacts 

The Immunization Information Services Support Branch (IISSB) supports the 

effort to recommend a standard transport option that grantee cities and states as 

well as other health care systems would support for immunization 

interoperability. 

Today, IIS in many settings have successful models for interoperability between 

numerous external systems including EHRs, vital records, Medicaid systems, 

WIC programs, and HMOs. Those interoperability models use a variety of 

transport layer protocols including SFTP, HTTPS, SOAP, REST, PHINMS, 

SMTP + S/MIME, and potentially others. There are also efforts to engage with 

an HIE in many locales. The expert panel acknowledges the large amount of 

interoperability effort already in place, or soon to be in place, and has no 

intentions or expectations to remove or interfere with those capabilities. 

Moving forward, the expert panel is recommending a transport layer protocol 

that will benefit the broadest area of health care systems to promote 

interoperability today and into the future. By working closely with AIRA, EHRA, 

IHS, ONC, and PHITPO on a standard interface, the IIS community can be 

confident their investment in SOAP will lead to a transport layer protocol external 

senders can use to quickly connect to their IIS. 

Moving into a SOAP web service will involve a commitment similar to any other 

enhancement to an IIS. While each IIS is in its own unique situation, for an IIS 

with a stable HL7 engine, adding the SOAP web service to transport the HL7 

message and its response should be a straight-forward development process. 

IIS that have implemented a SOAP service have been able to build their 

capabilities over time. This means it is entirely possible to build a simple SOAP 

service which only processes vaccination updates at first. Once stable, the IIS 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 26  

can then focus on expanding their SOAP service to handle query/response use 

cases. 

The final important positive impact to an IIS is the ability to add a SOAP service 

without disrupting existing transport layer protocols already in place. Existing 

providers using existing transport layer protocols can continue business as 

usual. New providers can be encouraged to use their EHR-supported SOAP 

interface and existing providers can be encouraged to adopt the SOAP service 

in due time. 

7.2. EHR Vendor Impacts 

EHR vendors and their clients at healthcare facilities will need to work with IIS to 

connect the software deployed at hospitals, clinics, and private doctor’s offices 

to the IIS. The Electronic Health Record Association (EHRA) supports the effort 

to recommend a single transport option that member companies would utilize for 

immunization interoperability. When technology companies need to assign 

resources for the same clinical functionality (exporting/importing immunization 

information to/from registries), but with different technical implementations, it 

increases the cost to the entire stakeholder base. By identifying SOAP as a 

recommended transport, EHR vendors will be able to focus on one transport 

protocol as a baseline for interoperability with immunization registries, while 

having a protocol that is scalable enough for the emerging requirements for 

query functionality. 

The level of interoperability achieved for short term benefits is a baseline 

standard across all participating immunization registries for a faster and less 

expensive deployment solution. A single recommended transport allows the 

vendor focus to be on clinical functionality, as opposed to resources spent on 

supporting multiple transports. A single transport recommendation should allow 

for cost savings to the stakeholder practices as a result of an interoperable 

solution that works across all participating registries. Consideration should be 

given to current development efforts of the EHR vendors as this transition to the 

recommended protocol is implemented. 

Two points of resistance to immunization reporting are development costs and 

the need for clinical staff to leave their EHR to obtain immunization information 

through a separate IIS web application. After the Transport Layer Workgroup 

implementation guide is complete and the nationally recommended SOAP 

interface is defined and implemented, the primary benefit to IIS will be that EHR 

vendors will be able to seamlessly exchange immunization information with 

immunization registries in both directions, with minimal effort. Ideally, the 

healthcare facility’s electronic system will only need to use the SOAP-enabled 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 27  

version of the EHR software, after technical staff has pointed it to the state, 

local, or regional immunization registry. In reality, some initial testing will be 

required before the integration between the EHR and IIS is used in production. 

7.3. Provider Impacts 

After the EHR systems are deployed in production, the lag between the date that 

a vaccine is administered and reported can be reduced to less than one day 

through real-time reporting. Use of real-time querying through an HL7 VXQ/QBP 

service will enable viewing of full immunization histories for patients that have 

been previously seen at other healthcare facilities and provide comprehensive 

display of vaccinations to date as IIS hold information from multiple sources of 

immunizations and hence help inform the healthcare provider. Decision support 

recommendations based on the ACIP immunization schedule will also be 

returned to the EHR by these services, which will help inform the clinician of 

valid/invalid vaccines in the patient’s record, along with the dates that the 

vaccines are due next, so that they can set their next appointment with the 

patient. 

Added future benefits to IIS include enabling the same seamless sharing of 

immunization information between different immunization registries and the 

potential for more services to be developed to provide more health information to 

the EHRs (e.g. lead screening, newborn screening, body mass index/height 

/weight, etc). 

If the provider has an existing stable exchange with the IIS and the IIS plans to 

continue support, there should be no immediate work for the provider. However, 

those providers looking to start an exchange with an IIS and those ready to 

move to real-time bidirectional exchange should evaluate their options with their 

IIS. Providers looking to create a SOAP exchange with their IIS will have coding 

samples and supporting documentation on the IIS Transport Layer Wiki to be 

used by their technical team or vendors. 

 

8. Conclusions

The expert panel recommends SOAP as a best practice transport layer with the goal 

of universal adoption by all IIS. However, this does not preclude other transport 

mechanisms from being utilized. The panel supports all transport methods discussed 

in this document and members look forward to promoting health system 

interoperability and assisting other IIS with data exchange efforts. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 28  

Implementation guidance will be made available by a Wiki. It will continue to be 

developed by the expert panel and include regular updates as they become 

available. The plans include but are not limited to: 

• Scope and audience for the Wiki 

• Lessons learned from IIS and EHR SOAP implementers 

• Case studies 

• SOAP tooling information and support 

• Community-wide standardized WSDL approach 

• Community-wide standardized authentication approach 

• Effort considerations for the IIS and EHR 

• Developers’ guide section for both senders and receivers including code 

samples 

• Contact information 

• SOAP specification document 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

 

Page | 29  

Appendices 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 30  

Appendix A: Subject Matter Experts 

Angel Aponte, New York Citywide Immunization Registry (CIR) 

aaponte@health.nyc.gov

Angel Aponte is a Computer Software Specialist at the Citywide Immunization 

Registry in New York City’s Department of Health and Mental Hygiene, with 10 

years of experience in the technical aspects of Immunization Information 

Systems, including software development in Java and .net, server systems, 

network troubleshooting, web application support and maintenance, relational 

database support and maintenance, data analysis, oversight of technology 

vendors and other technical partners, and writing/managing contract 

deliverables. Angel is a past co-chair of the American Immunization Registry 

Association (AIRA) Transport Layer Workgroup. 

Bob Barker, Electronic Health Record Association (EHRA) 

rbarker@nextgen.com

Robert Barker is the Manager of Interoperability and Standards for NextGen 

Healthcare, with experience in development of technology solutions across 

disparate platform vendors. He is currently the co-chair of the Electronic Health 

Record Association (EHRA) and has 10 years of experience in the Heath HIT 

community. 

Michael Berry, HLN Consulting, LLC / Rhode Island KIDSNET 

berrym@hln.com

Michael Berry is a project manager for HLN Consulting, LLC. He has worked on 

immunization information systems since 2003, with specific experience 

developing web-based and web services solutions for registries in Rhode Island 

and New York City. Since 2006 he has also been engaged in standards-based 

connectivity of Public Health to HIE, focusing on messaging architecture and 

privacy and security. 

Nathan Bunker, Dandelion Software & Research, LLC / ImmTrac (TX) 

nathan.bunker@gmail.com
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 31  

Nathan Bunker is an independent software developer, immunization registry 

consultant, and HL7 interface specialist with seven years experience working 

with various state and local immunization registries in the US. 

Marcelo Caldas, CDC Public Health Informatics and Technology Program Office 

(PHITPO) 

mcq1@cdc.gov

Marcelo Caldas is a Software Engineer with 14 years of experience in Web and 

SOA development. He’s been with Northrop Grumman working for the Centers 

for Disease Control and Prevention since 2004, engaged in several projects and 

currently supporting and enhancing the PHINMS product, a transport solution 

used by several public health partners nationwide for Heath Exchange 

Information. 

Concetto “Frank” Caniglia, American Immunization Registry Association (AIRA) 

ccaniglia@state.pa.us

Frank Caniglia is the IIS manager of the Pennsylvania Statewide Immunization 

Information System and has 15 years of experience in all aspects of IIS, 

including project management, technical support, interoperability, provider 

recruitment, training, policies and contracts. He is also a current Board Member 

of the American Immunization Registry Association (AIRA), member of the 

Modeling of Immunization Registry Operations Work Group (MIROW) Steering 

Committee, and AIRA Board representative to the Joint Public Health Informatics 

Taskforce (jPHIT). 

George Cole, Allscripts / Electronic Health Record Association (EHRA) 

george.cole@allscripts.com

George Cole is Principal Scientist, Integrated Solutions at Allscripts. He has 

been involved with EHR application interoperability for more than 7 years. 

George is a member of the EHRA Standards and Interoperability Workgroup, the 

IHE IT Infrastructure Technical Committee, the CDA Academy Faculty Board, as 

well as ASTM, IEEE, and ACM. He is co-editor of the IHE Retrieve Form for Data 

Capture (RFD) Profile and contributed code to the Direct Project reference 

implementation. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 32  

Emily Emerson, Minnesota Immunization Information Connection (MIIC) 

emily.emerson@state.mn.us

Emily Emerson is the IIS manager of the Minnesota Immunization Information 

Connection and has 10 years of experience in all aspects of IIS, including project 

management, technical support, provider recruitment and training, and policies 

and contracts. She is also the current president of the American Immunization 

Registry Association (AIRA) and co-chair of the AIRA Standards and 

Interoperability Steering Committee. 

Josh Friedman, Hewlett Packard (HP) 

friedman@hp.com

Joshua Friedman is a SOA architect for Hewlett Packard Enterprise Services, 

having designed systems for immunization registries for 5.5 years. He has 

experience designing Statewide IIS web services solutions for the states of 

Wisconsin and Oregon, in addition to custom soap based web services tooling 

and monitoring software. 

Paul Groll, Michigan Care Improvement Registry (MCIR) 

grollp@michigan.gov

Paul Groll, CISSP, is an Enterprise Architect with the State of Michigan, 

specializing mainly in solution and security design. He has worked on a number 

of large-scale integration projects for the state since 1994, with a focus on health 

systems since 2009. Paul is currently engaged in all design aspects of 

Michigan's internal Health Information Exchange, and provides technical 

representation for the state in the broader aspects of Michigan's state-wide HIN 

efforts. 

Gautam Kesarinath, CDC Public Health Informatics and Technology Program Office 

(PHITPO) 

gfk0@cdc.gov

Gautam Kesarinath is the Portfolio Manager and Enterprise Architect for CDC 

Public Health Informatics Technology Program Office (PHITPO). He was the 

program manager for PH interoperable systems including PHIN MS, PHIN VADS 

and Data Message Brokering at CDC between 2007 and 2010. He has 10 years 

public health experience at CDC and 18 years overall in technology management 

and systems architecture. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 33  

Thomas Maerz, Wisconsin Immunization Registry (WIR) 

thomas.maerz@wi.gov

Thomas Maerz is the Designer & Manager of the Wisconsin Immunization 

Registry which is used by numerous grantees nationwide. Having extensive 

applications development knowledge as well as being an experienced Network 

Engineer, he has 16 years of experience in all aspects of IIS, including project 

management, functional design, technical support, provider recruitment, training 

and the writing of technical support documents, policies, procedures and 

contracts. His additional experience includes working within Wisconsin's Vital 

Records system for 5 years and 11 years working as a Customer Support 

manager for an Electronic Medical Record vendor. 

Arien Malec, NHIN Direct 

arien.malec@nhindirect.org

Arien Malec is Coordinator, S&I Framework and Direct Project, for the Office of 

the National Coordinator (ONC). He has nearly 20 years experience in 

healthcare and life sciences software and informatics. He has held senior 

leadership positions in product management and services, most recently as Vice 

President, Product Management for RelayHealth, where he managed business 

strategy and requirements for Software as a Service platform providing HIE, 

EHR, and PHR capabilities. 

Ben Martinez, New Mexico Statewide Immunization Information System (NMSIIS) 

ben.martinez@state.nm.us

Ben Martinez is the Business/System Analyst assigned to the NM Immunization 

Information Registry with over 25 years in the IIS field, and has supported 

various state government agencies and applications, including health, finance, 

payroll, inmate information, and probation and parole. 

Deborah Rochat, Oregon ALERT IIS 

deborah.l.rochat@state.or.us

Deborah Rochat is an Operations Analyst for the Oregon Immunization ALERT 

IIS. She has over 12 years of data management and analysis experience in both 

public and private sectors, including four years of experience as the 

Immunization ALERT Data Quality Coordinator. Most recently she is working with 

ALERT on data conversion and migration efforts, as well as with interoperability 

grants. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 34  

David Rose, Scientific Technologies Corporation (STC)/ Washington CHILD Profile 

Immunization Registry 

david_rose@stchome.com

David Rose is the Solution Architect for Scientific Technologies Corporation, 

focusing on the interfaces between public health applications, including 

immunization registries and disease surveillance systems, and external systems, 

including EMR and EHR systems, laboratory LIMS, and HIE gateways. 

Purvesh Shah, NextGen Healthcare 

PShah@nextgen.com

Purvesh Shah is leading the development of Ordering system for NextGen 

Healthcare and has over 15 years of experience (7 years in healthcare) in all 

aspects of a software development life cycle, including requirements gathering & 

analysis, software architecture & development and mentoring other developers. 

He holds a Masters degree in Computer Science from St. Joseph’s University. 

Shane Speciale, Avanza Systems Inc. / South Dakota Immunization Information System 

shane@avanzasystems.com

Shane Speciale is the President of Avanza Systems, an immunization registry 

product manufacturer. Shane has been personally involved in the planning, 

design, development, implementation, and/or support of more than 20 

immunization registries at the local, state, and federal (DOD) levels over the past 

18 years and has intimate knowledge of and experience with HL7 data exchange 

and related transport. 

Cecile Town, Indian Health Service (IHS) 

cecile.town@ihs.gov

Cecile Town is a CDC Research Officer assigned to the Indian Health Service 

Immunization Program in Albuquerque, New Mexico. Since 2006, she has 

worked with IHS, IIS and vendor partners to establish standards-based interfaces 

between IIS and the IHS Resource and Patient Management System (RPMS). 

She is also a federal liaison to the American Immunization Registry Association 

(AIRA) Board of Directors. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 35  

Appendix B: Protocol Research Workgroups 

SOAP Web Service Workgroup

• Angel Aponte, New York Citywide Immunization Registry (CIR) 

• Nathan Bunker, Dandelion Software & Research, LLC 

• George Cole, Allscripts 

• Josh Friedman, Hewlett Packard (HP) 

• Deborah Rochat, Oregon ALERT IIS 

SMTP+S/MIME Workgroup

• Bob Barker, Electronic Health Record Association (EHRA) 

• Concetto “Frank” Caniglia, American Immunization Registry Association 

(AIRA) 

• Paul Groll, Michigan Care Improvement Registry (MCIR) 

• Gautam Kesarinath, CDC Public Health Informatics and Technology Program 

Office (PHITPO) 

• Arien Malec, Direct Project 

REST / HTTPS POST Workgroup

• Michael Berry, HLN Consulting, LLC 

• Ben Martinez, New Mexico Statewide Immunization Information System 

(NMSIIS) 

• David Rose, Scientific Technologies Corporation (STC) 

• Cecile Town, Indian Health Service (IHS) 

ebXML and ebMS Workgroup

• Marcelo Caldas, CDC Public Health Informatics and Technology Program Office 

(PHITPO) 

• Emily Emerson, Minnesota Immunization Information Connection (MIIC) 

• Tom Maerz, Wisconsin Immunization Registry (WIR) 

• Shane Speciale, Avanza Systems 

• Purvesh Shah, NextGen Healthcare 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 36  

Appendix C: Business Requirements 

Business 

Requirement 

# 

Subject Area Comment 

General Solution Requirements 

1 Payload Size The transport layer should support data 

transmissions of a significant size. This 

will allow for transmissions of large 

batches of data. 

2 Synchronous Response The transport layer should allow for the 

receiving system to return response(s) 

immediately. 

3 Asynchronous 

Response 

The transport layer should allow for the 

receiving system to acknowledge receipt 

of the payload and process the payload on 

its own schedule. The sender may check 

back at a later time for a response 

payload, or the receiver may initiate a 

response (reply) to the sender with the 

response payload. It is expected that the 

sender and receiver will support either a 

“check back” or an “unsolicited push or 

reply” response model, but not necessarily 

both models. 

4 Technology Neutral The transport layer must be language, 

platform, payload, message, and product 

agnostic. 

5 Technology Credibility The transport layer must be based on 

existing technologies with a proven 

successful health system to health system 

history supported by standards. 

6 Secure Transmission The transport layer must provide support 

for a secure point-to-point transmission of 

PHI and PII related data. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 37  

7 Reliable Transmission The transport layer must provide support 

for a reliable point-to-point transmission of 

PHI and PII related data. Reliable 

transmission includes ensuring the 

message has successfully made it from 

source to destination and providing a 

framework to deal with unsuccessful 

transmissions, Errors during transmission, 

and the ability to resubmit an unsuccessful 

transmission. 

8 Authentication The transport layer must provide an easily 

implemented and maintained system-tosystem authentication framework/protocol. 

This score should also consider 

operational management as the number of 

external systems increases. 

IIS or Receiver Requirements 

9 Ease of Implementation The transport layer must be easy to 

implement for an IIS. 

10 Ease of Maintenance The transport layer must be easy to 

maintain for an IIS. 

11 Scalable The transport layer must be able to 

efficiently handle increases in serial and 

parallel requests to the IIS as the number 

of external systems that communicate with 

the IIS simultaneously increases. 

12 Ease of Use The transport layer must provide 

effectiveness, efficiency, and satisfaction 

with which the intended users can achieve 

their tasks in the intended context of 

product use. 

13 Performance The transport layer must provide 

framework to achieve service quality to the 

user from the start to the finish of a given 

task. However, it must not degrade other 

system services to accomplish its task. 

14 Cost Effective The transport layer must be as cost 

effective as possible for the IIS. 

External System or Sender Requirements 

15 Ease of Implementation To achieve an optimal score the transport 

layer must be easy to implement for an 

EHR. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 38  

16 Ease of Maintenance To achieve an optimal score the transport 

layer must be easy to maintain for an 

EHR. 

17 Scalable The transport layer must be able to 

efficiently handle increases in the number 

of users, patients, and vaccines in the 

EHR system. 

18 Ease of Use The transport layer must provide 

effectiveness, efficiency, and satisfaction 

with which the intended users can achieve 

their tasks in the intended context of 

product use. 

19 Performance The transport layer must provide 

framework to achieve service quality to the 

user from the start to the finish of a given 

task. However, it must not degrade other 

system services to accomplish its task. 

20 Cost Effective The transport layer must be as cost 

effective as possible for the EHR. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 39  

Appendix D: Use Cases 

HL7 2.5.1 Use Cases 

Use 

Case 

Title Goal 

1 Send Immunization History To send an immunization history for an individual 

client from one system to another. In addition to 

EHR-S and IIS, other systems such as vital records 

systems or billing systems could use this message 

to send immunization histories. 

2 Receive Immunization History To receive an unsolicited immunization history. It 

may be an update or a new record. This use case 

does not have responsibility for the processing of 

the message. The receiving system may review and 

accept the immunization history if it chooses, but 

this outside the scope of this use case. 

3 Request Immunization History To request an immunization history from another 

system. 

4 Return Immunization History To return an immunization history. It does not 

include the processes used to find candidate clients 

4A Find Candidate Clients To find one or more candidate clients from another 

system and select one to be used when requesting 

an immunization history. 

5 Accept Requested History To accept an immunization history in response to a 

query for an immunization history from another 

system. 

6 Send Demographic Data To send demographic data about a person. It may 

be an update or a new record. This use case does 

not have responsibility for the processing of the 

message. The message will include an indication of 

the expected/requested acknowledgement. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 40  

7 Accept Demographic Data To accept demographic data about a person. It may 

be an update or a new record. This use case does 

not have responsibility for the processing of the 

message. The message will include an indication of 

the expected/requested acknowledgement. 

8 Acknowledge Receipt To acknowledge receipt of a message. This can be 

an immunization history, request for immunization 

history, demographic update, observation report or 

request for personal id. It may indicate success or 

failure. It may include error messages. One 

example occurs when a query is well-formed, but 

finds no candidates. In this case the 

acknowledgement reports this fact. 

9 Report Error To send error messages related to messages. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 41  

Appendix E: Comparison by Defined Business Requirements 

Payload Size: The transport layer should support data transmissions of a significant 

size. This will allow for transmissions of large batches of data. 

ebXML: 

• ebXML has no limitation

• Older versions of PHINMS had limitations. Newer versions of PHINMS can 

chunk the file to allow for larger payloads and is now more limited by the runtime 

environment rather than the transport. Newer versions have tested transporting 

up to a 5GB payload.

SMTP+S/MIME: 

• There is no limitation on payload size with SMTP+S/MIME. 

• However, most email gateways are configured to block messages over a certain 

size based on policy decisions by the receiving entity. 

HTTPS POST/REST: 

• No limitations to payload. Large files are very normal in many IIS using HTTPS 

POST. 

• 150 MB in WIR-based applications, but constrained to 150 MB by the application 

not the transport. 

• HTTP supports compression to aid in transport performance as the payload size 

increases. 

• RESTful architectures follow the Atom Publishing Protocol for attachments, using 

the POST (or PUT) verb to submit a resource (file). 

SOAP: 

• There is no size limitation from a transport perspective. 

• The panel noted two approaches for large payloads via SOAP. 

o Message Transmission Optimization Mechanism (MTOM) 

o SOAP with Attachments (SwA) 

· It is acknowledged that MTOM is more efficient for large payloads 

than SOAP with Attachments is. “Large” would need to be defined, 

but MTOM offers performance improvements. 

· MTOM has been adopted by IHE XDS.b profile. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 42  

Synchronous Response: The transport layer should allow for the receiving system to 

return response(s) immediately. 

ebXML: 

• ebXML could be built to be entirely synchronous from the EHR into the IIS and 

back. 

• PHINMS as it is implemented today falls short of a true synchronous response 

due to the required EHR file poling in the PHINMS directories for a response. 

• It is important to note that “round trip” performance times are still achievable as 

proven by both Minnesota and Wisconsin. 

SMTP+S/MIME:

• SMTP+S/MIME do not support a synchronous response. 

HTTPS POST/REST: 

• By definition, HTTPS request/response model is synchronous. 

• Since a RESTful architecture is implemented using HTTPS as its underlying 

transport, it supports synchronous response. 

SOAP: 

• When implemented as SOAP over HTTPS, then by definition of HTTPS, it is 

synchronous. 

• A graphical view of New York City’s synchronous queries over time is shown 

below. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 43  

0

20000

40000

60000

80000

100000

120000

140000

Number of Requests

Month

HL7 Web Service SearchActivity By Month

January 2010 ‐ January 2011

Searches

Successful

Searches

• In addition to synchronous query/response processing, New York City has also 

started processing unsolicited vaccination updates (VXU) synchronously using 

their SOAP web service. 

• While Oregon had not implemented their SOAP service in 2010, they have a 

similar graph of potential Web Service queries (to understand potential volume) 

based on their IIS usage. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 44  

0

10,000

20,000

30,000

40,000

50,000

60,000

70,000

80,000

90,000

100,000

Jan‐10 Feb‐10 Mar‐10 Apr‐10 May‐10 Jun‐10 Jul‐10 Aug‐10 Sep‐10 Oct‐10 Nov‐10 Dec‐10 Jan‐11 Feb‐11

Number of Requests

Month

Oregon ImmunizationALERT Web Search Activity By Month

January 2010 ‐ February 2011

Web Searches

Successful Searches

Asynchronous Response: The transport layer should allow for the receiving system to 

acknowledge receipt of the payload and process the payload on its own schedule. The 

sender may check back at a later time for a response payload, or the receiver may 

initiate a response (reply) to the sender with the response payload. It is expected that 

the sender and receiver will support either a “check back” or an “unsolicited push or 

reply” response model, but not necessarily both models. 

ebXML: 

• Both “check back” and “unsolicited push or reply” models could be implemented. 

• It is noted that the “check back” model would be easier to implement and 

maintain for the sender. 

SMTP+S/MIME:

• SMTP+S/MIME supports an “unsolicited push or reply” asynchronous response 

model. 

HTTPS POST/REST: 

• HTTPS POST could easily be implemented to support an asynchronous 

response. It could support both a “check back” model by the sender as well as 

an “unsolicited push or reply” model. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 45  

• While it would be possible to support either model, it is much easier implemented 

(and maintained) as a “check back” model where the sender is responsible for 

retrieving the response. 

o IHS (sender) has an asynchronous model in Arizona and Utah. 

o IHS (sender) is responsible for picking up the response. 

o IHS (sender) payload size is roughly 4 -5 MB per day during the week and 

2 MB on the weekends. 

• HTTPs GET would be used to retrieve the response. In a RESTful architecture, 

the sender would be responsible for retrieving the resource (response payload). 

SOAP: 

• SOAP could easily be implemented to support an asynchronous response over 

HTTP. It could support both a “check back” model by the sender as well as an 

“unsolicited push or reply” model. 

• While it would be possible to support either model, it is much easier implemented 

(and maintained) as a “check back” model where the sender is responsible for 

retrieving the response. 

• Wisconsin is working on an asynchronous model for providers who submit large 

batches of data. 

Technology Neutral: The transport layer must be language, platform, payload, 

message, and product agnostic. 

ebXML: 

• The ebXML standard has no limitations or restrictions to a language, platform, 

payload, or product. 

SMTP+S/MIME:

• Both SMTP and S/MIME specifications have no limitations or restrictions to a 

language, platform, payload, or product. 

HTTPS POST/REST: 

• The HTTP(s) protocol has no limitations or restrictions to a language, platform, 

payload, or product. 

• The RESTful architecture uses HTTP(s) as its transport for transmission from 

source to destination. As such, there is no language, platform, payload, or 

product specific technology that is required to implement. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 46  

SOAP: 

• The SOAP protocol specification has no limitations or restrictions to a language, 

platform, payload, or product. 

Technology Credibility: The transport layer must be based on existing technologies 

with a proven successful health system to health system history supported by 

standards. 

ebXML:

• ebXML is a family of XML-based standards sponsored by OASIS and 

UN/CEFACT whose mission is to provide an open, XML-based infrastructure that 

enables the global use of electronic business information in an interoperable, 

secure, and consistent manner by all trading partners.8

• In the Minnesota Immunization Information Connection (MIIC): 

o The healthcare systems are using Allscripts/Touchworks and the second 

the shot is added in the EHR, it is sent off to MIIC. 

o Below is a snapshot from Tuesday 2/8/2011. 

· HIE using VXQ COMPLETE (5) 

· Health System A sending VXU: COMPLETE (543) 

· Health System B sending VXU: COMPLETE (148) 

• In the Wisconsin Immunization Registry (WIR) 

o ebXML transport is being used to submit/query HL7 payloads by EPIC, 

Cerner, and RPMS. 

o WIR processed 1 million VXU messages via ebXML in 2009. 

• The state of Georgia IIS also uses ebXML for transport of messages. 

SMTP+S/MIME:

• Simple Mail Transfer Protocol (SMTP) is an Internet standard for electronic mail 

(e-mail) transmission across Internet Protocol (IP) networks. SMTP has been 

defined through several RFCs and is in widespread use today. 

• Secure/Multipurpose Internet Mail Extensions (S/MIME) is a standard for public 

key encryption and signing of MIME data. S/MIME is on an IETF standards track 

and defined in a number of documents. 

• IIS Usage: 

o ABILITY Network, Inc., a Healthcare Internet Service Provider (HISP), is 

currently receiving SMTP+S/MIME immunization messages from a 

provider in Minnesota and then passing those messages to the Minnesota 

                                                           

8 ebXML – Wikipedia http://en.wikipedia.org/wiki/EbXML (Feb. 14, 2011)
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 47  

IIS via Public Health Information Network Messaging System (PHIN-MS), 

an ebXML-based transport protocol. 

o ABILITY Network, Inc. is working on a similar SMTP+S/MIME to PHIN-MS 

message transmission in Oklahoma. 

• Other healthcare related information exchanges using SMTP+S/MIME are as 

follows: 

o Rhode Island’s implementation of a provider-to-provider directed 

exchange uses the SMTP+S/MIME protocol. 

o Various EHR directed pushes to PHRs use SMTP+S/MIME. 

o Veterans Affairs Medical Center mammography referrals to a private 

sector clinic occur via SMTP+S/MIME. 

• The Applicability Statement 1 (AS1) specification for Electronic Data Interchange 

(EDI) is very similar to SMTP+S/MIME (as defined by the Direct Project) and has 

been in broad use in the EDI industry for some time. 

• SMTP+S/MIME introduces a transport protocol that isn’t widely used today by 

existing operational EHR’s or IIS’s. 

• Looking ahead at Meaningful Use Stage 3 requirements for immediate 

immunization query and response by the EHRs into the IIS is not a strong suit for 

SMTP+S/MIME. 

HTTPS POST/REST 

• HTTP standards development has been coordinated by the Internet Engineering 

Task Force (IETF) and the World Wide Web Consortium (W3C). Their work 

created RFC 2616 which defines HTTP/1.1 standard. 

o While HTTP is a standard, the implementation of HTTPS POST as a 

standard transport protocol isn’t. It isn’t known to be a common, or 

standard, approach to messaging outside of the IIS community. 

• HTTPS POST was the recommended by the “HL7 Immunization Registry Task 

Force sub group on HTTP message transport” in 2002. 

• HTTPS POST is currently being supported by at least 20 IIS which include but 

are not limited to the following IIS: 

Alaska Arizona Idaho Indiana Louisiana 

Maine Maryland Minnesota Mississippi Missouri 

Montana (in progress) New Jersey Oregon Rhode Island South Dakota 

Utah Washington West Virginia Wisconsin Wyoming 

• Indian Health Services (IHS) submits data with the following IIS using HTTPS 

POST: 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 48  

Alaska Arizona Idaho Louisiana Maine Mississippi 

Montana (in progress) San Diego South Dakota Washington Wyoming 

• IHS sends out HL7 messages to the following IIS using an HTTPS POST upload 

feature of the IIS: 

Minnesota Utah Wisconsin 

• There is no official standard for RESTful web services. This is because REST is 

an architecture and not a protocol. Even though REST is not a standard, a 

RESTful implementation can use standards like HTTP, URL, XML, PNG, etc. 

• RESTful implementations have broad adoption across many different industries 

including e-prescribing. 

• There are no known live or planned RESTful IIS implementations to date. 

SOAP: 

• The SOAP 1.2 standard is maintained by the XML Protocol Working Group of the 

World Wide Web Consortium (W3C). 

• Of the 20 grantees represented on this panel, New York City has a live SOAP 

Web Service with Colorado, Oregon, Utah, and Wisconsin planning or actively 

working on a SOAP Implementation. 

o New York City Usage 

· In 2010, New York City processed over 417,136 HL7 2.3.1 VXQ 

query/response messages from one large hospital network. 

· Between 01/27/2011 and 02/23/2011, 10,137 VXU messages were 

received from one EMR system spanning 5 healthcare facilities. 

o New York City’s Planned Growth 

· By August 31, 2011, New York City plans to be exchanging with 

150 healthcare facilities. 

· By August 31, 2012, New York City plans to be exchanging with an 

additional 200 healthcare facilities. 

o In 2011, New York City is actively working to bring on 8 of their larger EHR 

systems. 

o Wisconsin has a SOAP Implementation live in production and is working 

to bring on providers in the near future. 

o Colorado and Oregon are working to implement their SOAP service. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 49  

· Oregon intends to implement HL7 messaging with 30 partners (133 

physical sites) over an 18 month period. The sites are being 

strongly encouraged to use their SOAP web service. 

· 9 partners (83 physical sites) are working in conjunction with 

Oregon’s go-live plan and looking to exchange HL7 messages 

starting in spring 2011. 

· In total, Oregon is planning to work with 15 EHR vendors as part of 

this project. 

o Colorado, Oregon, and Wisconsin have all agreed to a common Web 

Service Definition Language (WSDL) which will allow for easier EHR 

adoption. 

o The 2011 IHE Connectathon included 40 EHR’s which support the SOAPbased IHE XDS.b profile. 

Secure Transmission: The transport layer must provide support for a secure point-topoint transmission of PHI and PII related data. 

ebXML: 

• The Message Service Specification (ebMS) describes a communication-neutral 

mechanism Message Service Handlers (MSH) must implement in order to 

exchange business documents. 

• Based on the ebMS specification, the underlying transport protocol (HTTP, 

SMTP, etc...) is open for design time decisions. 

o Wisconsin, Minnesota and Georgia use HTTPS as their underlying 

transport to support ebXML specifications based on a few factors 

including: 

· It is easier to implement than SMTP for the IIS and the EHR. 

· The IIS’s were currently live with an HTTPS port already listening to 

the outside world. 

· The use of ebXML didn’t require an additional interface with an 

email server or directory polling for the incoming payload. 

· It allowed for synchronous processing of real-time messages 

supporting immunization updates and query/response processing. 

• Transport Layer Security (TLS) cryptographic protocol provides communication 

security over the internet. 

SMTP+S/MIME:

• S/MIME is used to encrypt the message and payload. However, it does not 

encrypt the “from”, “to”, “subject”, nor any other e-mail header field. These are 

transported as clear text. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 50  

• S/MIME supports 128 and 256-bit encryption. 

HTTPS POST/REST: 

• Transport Layer Security (TLS) cryptographic protocol provides communication 

security over the internet. 

SOAP: 

• SOAP supports different transport layers with HTTP and SMTP being the most 

common implementations. 

o New York City, Oregon, Wisconsin, and Colorado have chosen HTTPS as 

their transport layer for few reasons including: 

· HTTPS is easier to implement than SMTP for the IIS and EHR. 

· The IIS’s were currently live with an HTTPS port already listening to 

the outside world. 

· It didn’t require an interface with an email server or directory polling 

for the incoming payload. 

· HTTPS allowed for synchronous processing of real-time messages. 

· It is easier for data exchange providers from a “sending” standpoint 

based on their IT environment. 

• Transport Layer Security (TLS) cryptographic protocol provides communication 

security over the internet. 

Reliable Transmission: The transport layer must provide support for a reliable point-topoint transmission of PHI and PII related data. Reliable transmission includes ensuring 

the message has successfully made it from source to destination and providing a 

framework to deal with unsuccessful transmissions, Errors during transmission, and the 

ability to resubmit an unsuccessful transmission. 

ebXML: 

• ebXML supports reliable message delivery based on the WS-Reliability and WSReliableMesaging specifications. 

SMTP+S/MIME: 

• Message Disposition Notification for success or failure and reason for failure. 

Message Disposition Notification is an IETF standard. 

• The “Message-ID” in the message header of SMTP can be used to check for 

duplicate messages during IIS processing to quickly determine if a message is a 

duplicate and doesn’t need to be processed. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 51  

o Further, the Message-ID can be used for correlated workflows where the 

reply to an initial payload could be correlated through the Message-ID. 

• Given the use of X.509v3 standards for public key infrastructure (PKI) to create 

trust policies between the sender and the receiver, it is recommended to turn off 

Spam detection software to avoid trusted messages from being blocked or not 

delivered to the inbox. Further, configuration settings should prevent non-trusted 

emails from entering the inbox. It is also recommended to separate work-related 

“Direct” emails from personal emails through separate email accounts. 

HTTPS POST/REST: 

• HTTPS uses the HTTP response status codes for the sender to ensure reliable 

transmission of the message. 

SOAP: 

• New York City addressed reliable transmission with their senders by having them 

resubmit any message they felt didn’t yield an expected response. The expected 

response can be a few different things depending upon the use case, but is 

usually an ACK, ERR, or query response. Since the Citywide Immunization 

Registry (CIR), and all other IIS, must properly apply business rules (de-duplicate 

immunizations, update addresses, etc.), potentially receiving and processing a 

message twice is not harmful to the IIS or its data. 

• Wisconsin looked into WS-ReliableMessaging, but found it to not be beneficial for 

their use and appeared to add some overhead without value. Similar to New 

York City, the Wisconsin Immunization Registry (WIR) also has the responsibility 

to apply appropriate business rules of incoming data, so seeing a duplicate 

message is not harmful to the IIS or its data. 

• SOAP Faults can be used to properly address the failed SOAP transmission and 

determine what actions to take based on the failed transmission. 

Authentication: To achieve an optimal score, the transport layer must provide an easily 

implemented and maintained system-to-system authentication framework/protocol. This 

score should also consider operational management as the number of external systems 

increases. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 52  

                                                           

ebXML: 

• Collaborative Partner Profile Agreements are XML-based documents specifying 

a trading agreement between trading partners. Each trading partner will have 

their own Collaboration Protocol Profile (CPP) document that describes their 

abilities in an XML format. For instance, this can include the messaging protocols 

they support, or the security capabilities they support. A CPA document is the 

intersection of two CPP documents, and describes the formal relationship 

between two parties. The following information will typically be contained in a 

CPA document: 

o Identification information: the unique identifiers for each party and their 

roles within the trading relationship 

o Security information: for instance, are digital signatures required, and what 

algorithms do they use. 

o Communication information: the protocols that will be used when 

exchanging documents. 

o Endpoint locations: the URL to which service and action messages should 

be sent. 

o Rules to follow when acknowledgments are not received for messages, 

including how long to wait before resending, and how many times to 

resend. 

o A decision on whether duplicate messages should be ignored 

o A decision on whether acknowledgments are required for all messages9

• It is important to note that for each sender there must be a CPP Agreement 

between the sender and the receiver, meaning the receiver must maintain a CPA 

document for each sender. As the list of senders grows, the list of CPA’s the 

receiver is responsible for also grows. From a maintenance standpoint, tracking 

all of the CPA’s could become a substantial effort. 

o Wisconsin has worked to operationalize and mitigate this concern over the 

years since its initial implementation in 2003. 

SMTP+S/MIME:

• SMTP+S/MIME authentication, or trust model, within the Direct Project is to use 

the ITU-T X.509v3 standards for public key infrastructure (PKI) based on IETF 

Internet certificate profiles (PKIX) will enable Direct Project users to create trust 

policies that enable network encryption by the use of digital certificates, public 

and private keys and certificate authorities. The content encapsulated in the 

messaging protocol is secured using the Secure/Multipurpose Internet Mail 

Extensions (S/MIME) protocols. 

9 ebXML – Wikipedia http://en.wikipedia.org/wiki/EbXML (Feb. 15, 2011)
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 53  

HTTPS POST/REST 

• Today, most IIS implementations perform authentication by passing name value 

pairs in the body of the POST which include a username, password and in some 

cases a facility ID. This approach mimics a web-form and follows the Transport 

of Immunization HL7 Transactions over the Internet Using Secure HTTP version 

1.0 by the HL7 Immunization Registry Task Force subgroup on HTTP Message 

Transport. 

• Authentication occurs during each transaction (trip). 

• It could be possible to extend this model for session-based “conversations” 

where once the sender is authenticated, multiple transactions (trips) could be 

made without being required to authenticate with each trip. A logout or timeout 

would require the sender to authenticate again. 

• It would be entirely feasible to consider other authentication methods such as 

Basic Access Authentication or Digest Access Authentication for continued 

sender simplicity. 

• While no REST IIS implementations exist, it is agreed the HTTPS POST 

approaches can be applied to a RESTful architecture. 

• Other authentication approaches to explore include Public Key with client 

certificates, SAML Tokens and Secure Remote Password protocol. 

SOAP: 

• New York City uses HTTP Basic Authentication which includes a facility ID, 

password, and a CIR created Identity Key for each provider. The identity key is a 

long string unique to each sender. 

o New York City considered using a facility ID, password, and client certificate, 

but opted against it at this time for simplicity and maintenance ease. Their 

design doesn’t prevent them from considering a client certificate in the future. 

• WIR-based IIS will be using a custom CA Certificate for authentication. Each 

sender will have an individual certificate. WIR is building a “sender bundled 

package” which can be easily installed by the sender and provide a simple API to 

the EHR for calling off to the registry. The bundled package will contain the 

individual certificate. 

o WIR is also planning to use SAML tokens with Epic and possibly other large 

providers 

o Small providers will use the WS-Security Username Token Authentication 

• Authentication in both scenarios happens with each transaction. Neither New 

York City nor Wisconsin has seen a performance issue with that approach. 

• In comparing the two methods of authentication, the subgroup agreed that 

maintenance in Wisconsin is likely larger than New York City but more secure. 

Maintenance is larger because certificates expire and must be reissued, the 

sender could change IP addresses rendering the certificate invalid. Wisconsin is 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 54  

more secure because client certificates ensure the message is truly coming from 

the sender it purports to be. 

• VPN could be considered, but it is known to have scalability issues from an 

operational standpoint to be viable. 

IIS or Receiver Requirements 

Ease of Implementation: The transport layer must be easy to implement for an IIS. 

ebXML: 

• Wisconsin implemented in 2003. At that time, WIR implementation took several 

months and was very complex to install, configure and test. Wisconsin’s ebXML 

implementation uses the PHINMS product and required very little custom coding. 

It took several months from the start of the project to Go-Live. 

o Support issues from the CDC related to installation and usage for an IIS 

setting were difficult to work through at the time of installation. 

• Minnesota’s implementation (2008) followed a similar story to Wisconsin’s effort, 

and they also opted to install PHINMS. The two install models are slightly 

different based on state data center policies and overall architecture vision from a 

central IT perspective, but the install and configuration process was very time 

consuming. It took Minnesota several months from the start of the project to GoLive. 

• The silver lining between Wisconsin and Minnesota is the flexibility in ebXML to 

support the different architectures. Both approaches proved to be successful 

with minor configuration and coding changes between the two states. 

• ebXML as a whole is complex and overall knowledge is limited which often leads 

to large learning curves and implementations which take longer than first 

anticipated. 

SMTP+S/MIME:

• From an IIS setting, it is not entirely clear how long it will take to fully implement 

an SMTP+S/MIME solution or exactly how complex it will be. 

o SMTP+S/MIME are familiar and heavily used in IT which will allow for 

easier acceptance through governance procedures. 

• John Halamka, CIO at Beth Israel Deaconess Medical Center (BIDMC), wrote on 

his blog “BIDMC engineers installed the open source Direct Gateway inside the 

BIDMC firewall. They worked with Healthvault engineers to exchange certificates 

so that the digital signing and encryption aspects of Direct's S/MIME 

implementation would guarantee data security and integrity. BIDMC engineers 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 55  

then sent my Continuity of Care Record and Continuity of Care Document via the 

Direct gateway to my secure Health email address.” 

o This implementation was performed in 1 day. This implementation and its 

supported use case is different than some of the EHR to IIS use cases but 

does show some of the flexibility and ease with which SMTP+S/MIME can 

be implemented. 

• Pennsylvania and Michigan estimate the project to be a few months for an 

SMTP+S/MIME implementation. 

o It is anticipated to take a few months due to the following reasons (there 

may be other reasons): 

· State Data Center interaction/timeline. 

· Potential additional interface required to complete the delivery of 

email to the IIS server for processing. 

· Creation of a sweeping program to monitor incoming directory for 

the payload for processing. 

· Creating a reply (once processing is finished) message involves 

sending an SMTP+S/MIME message back. Again, another 

interface with an email server may be required. Some IIS can send 

outbound email directly from the IIS server. Others are restricted 

from sending email due to policy. 

· Lack of development knowledge on IIS development team or with 

IIS vendor to properly and quickly implement SMTP+S/MIME. 

♦ Reference Implementations aid in mitigating the learning 

curve. 

· How does an IIS map the PKI trust model into a facility in the IIS for 

processing? Most IIS operate on a purely web-based authentication 

model of username and password for identity. 

♦ Could look at mapping incoming email address into the IIS 

user or facility for processing. 

· Capacity planning. 

· Governance Issues. 

HTTPS POST/REST: 

• HTTPS POST can be implemented easily through common tools already used by 

an IIS development team. 

• There is a very small learning curve for HTTPS POST due to the use of existing 

tools and the HTTP model most IIS staff are already familiar with. 

• HTTPS POST implementation timeframe can be measured in weeks versus 

months based on Transport of Immunization HL7 Transactions over the Internet 

Using Secure HTTP version 1.0. With existing web-based IIS, most of the 

framework and architecture are already in place. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 56  

• REST is not drastically different than HTTPS POST. There is a bit of a learning 

curve that may not exist in HTTPS POST for those unfamiliar with a RESTful 

architecture, but it would add an architecture over raw HTTPS POST. 

o Making the step from HTTPS POST up to a full RESTful architecture would 

be very manageable. 

• There are no known REST IIS implementations to refer to, but it is believed the 

timeframe would be slightly longer than an HTTPS POST implementation due to 

the learning curve. 

Ease of Implementation 

SOAP: 

• New York City: 

o It took about 6 months to implement. 

o Implementation was completed in 2009. 

o If NYC had to do it again, they could probably do it more efficiently with 

generation tools such as Java2WSDL to reduce the implementation 

timeframe. 

o Overall, it was a straightforward implementation in Java in Linux using 

Apache AXIS. 

• Wisconsin: 

o Java implementation on Linux was deployed using Glassfish. 

o WI took roughly 6 months to implement. 

• Oregon: 

o Oregon is leveraging WIR’s SOAP implementation. Configuration issues 

were based on mildly different architectures (Proxy server and Solaris), but 

they have resolved those configuration issues. 

o Implementation time will also be measured in months. 

Ease of Maintenance: The transport layer must be easy to maintain for an IIS. 

ebXML: 

• The Wisconsin maintenance story is much different than the install story. Once 

the install was complete, the ebXML transport piece is usually an afterthought on 

a daily basis. Once live with a provider, one or two support calls per year would 

be a lot. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 57  

o Subsequent installs (due to new servers) has become easier. Initial 

learning curve is more problematic than subsequent installs. 

• Minnesota echoes Wisconsin in maintenance. Once the implementation hurdles 

have been cleared, maintenance has been very minimal. 

SMTP+S/MIME: 

• There are no operational IIS to reference at this point. 

• Email services can go down and may go down for a day. Operationally, this 

wouldn’t be acceptable for an IIS and its Service Level Agreements. 

HTTPS POST/REST: 

• Known situations which have caused issues have been SSL certificate changes 

and also using a lesser-known certificate. There have been issues with lesserknown certificates and trust by client-side applications. 

• From a pure transport perspective, daily maintenance is very minimal, and there 

are very few support calls directly related to the transport. 

• With no known REST implementations, it can only be assumed that maintenance 

would be very similar to HTTPS POST. 

• It is possible with a RESTful architecture, there will be a bit more complexity due 

to the use of more HTTP verbs (GET, PUT, and DELETE). 

SOAP: 

• NYC: 

o From a transport perspective, there is minimal daily effort or issues. 

o New Provider Rollout 

· It included a confidentiality agreement for the EHR vendor and 

healthcare facility. 

· A test environment account was created. 

• Some providers run with it and are successful; others ask 

questions and require a bit more support to get up and 

running. 

• Once the provider is ready for formal test, the provider sends 

a month worth of data through single transactions. 

· With increased staff, CIR staff can now work in greater detail with 

providers to ensure a more successful and repeatable process to 

provider roll-out. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 58  

o No major issues or special consideration would be required for new server 

install. 

• WIR: 

o Recently went live (January 2011), so very early in the maintenance 

process. Working to bring up the first provider. 

o Support from Glassfish has been very good. 

• Oregon: 

o As of mid-February 2011, Oregon is actively testing their SOAP interface 

and working towards a Spring 2011 Go-Live. 

Scalable: The transport layer must be able to efficiently handle increases in serial and 

parallel requests to the IIS as the number of external systems that communicate with 

the IIS simultaneously increases. 

ebXML: 

• There are no known limitations in a real-time setting where the payload is small. 

• When the payload becomes larger, ebXML doesn’t offer a framework for 

chunking the payload to support transmission of large payloads. Newer versions 

of PHINMS can chunk data to support larger payloads. If creating an ebXML 

transport (not PHINMS or any other product), the chunking component would 

have to be addressed. 

SMTP+S/MIME:

• From a transport perspective, there are no anticipated scalability issues. 

HTTPS POST/REST: 

• There are no known scalability issues with HTTPS or the implementation 

approach to HTTPS POST. 

• While there are no known REST implementations by an IIS, there are numerous 

implementations of REST both in healthcare and web-world as a whole. The 

underlying transport to REST is HTTP which has proven very scalable. 

• It is acknowledged that there is a potentially longer timeframe from the start of 

the project to Go-Live for REST. 

SOAP: 

• No known scalability issues 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 59  

• New York City sees multi-threaded submission and processing from sending 

providers which is handled easily through New York City’s SOAP service 

allowing for simultaneous messages from a single provider. 

Subject Area: Ease of Use: The transport layer must provide effectiveness, efficiency, 

and satisfaction with which the intended users can achieve their tasks in the intended 

context of product use. 

 

ebXML: 

• A large payload size can cause an operational issue. 

o In an older PHINMS implementation this can lead to the PHINMS 

component “freezing” until it is restarted. 

• There are numerous toolkits in support of ebXML development and maintenance 

ranging from open source to privately licensed software. 

SMTP+S/MIME:

• From a development standpoint, numerous SMTP+S/MIME development and 

support toolkits exist ranging from open source to privately licensed software. 

• The Direct project has two reference implementations in different programming 

languages. 

HTTPS POST/REST: 

• Development and monitoring tools exist in nearly all major programming 

languages for HTTP and HTTPS. 

• Existing tools used by IIS development staff could be used without the need for 

new tools or learning curve. 

SOAP: 

• From a development standpoint, multiple SOAP development and support 

toolkits exist ranging from open source to privately licensed software. 

• A large community of practice, web resources, tutorials and example code all 

freely exist to make ease of use very attractive. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 60  

Performance: The transport layer must provide framework to achieve service quality to 

the user from the start to the finish of a given task. However, it must not degrade other 

system services to accomplish its task. 

ebXML: 

• Payload size may be bloated based on the SOAP with Attachments specification 

ebXML implements for attaching payloads. 

• It is expected, but not proven, that ebXML may perform slightly slower than other 

frameworks due to the flexibility and complexity within the ebXML specification 

not found in other frameworks. 

• In Wisconsin, an HL7 message query and response “round trip” usually takes 

around 3 to 4 seconds. 

SMTP+S/MIME:

• Currently there are not enough SMTP+S/MIME implementations to prove 

performance, but at this time there are also no known concerns with this 

approach related to performance from a transport perspective. 

• When looking at the HL7 use cases which must be supported, it is acknowledged 

that SMTP+S/MIME has limitations in a query/response model where response 

time must be within seconds in order to repaint an EHR screen. 

HTTPS POST/REST: 

• There are no known limitations in the HTTPS transport protocol which would 

cause performance degradation or a disruption to existing IIS services and/or 

end users. 

• In use, HTTPS POST has proven to be a very solid solution with great round trip 

response times. 

SOAP: 

• SOAP with Attachments can create bloat with large payloads. 

o This is mitigated by using Message Transmission Optimization 

Mechanism (MTOM) rather than SOAP with Attachments. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 61  

• There are no known limitations when working with small quick individual 

transactions. 

Subject Area: Cost Effective: The transport layer must be as cost effective as possible 

for the IIS. 

ebXML: 

• With a canned product (such as PHINMS), there is considerable installation, 

configuration and testing time, but far less than creating an ebXML framework 

from the ground up. 

• Creating an ebXML framework would be a substantial undertaking involving 

several people and measured in months of effort, not weeks. Possibly some 

open source ebXML frameworks could be used to aid in development time. 

SMTP+S/MIME:

• Certificate costs will be an initial and on-going cost ranging from $100 - $900 per 

certificate per year. 

• Verizon Business runs a large number of trust services and they are currently 

offering zero dollar certificates for the provider. 

• Most Direct Project implementations have been able to use existing email 

servers to avoid the purchase of specific hardware for the project. 

• There is potentially a nominal fee from State Data Center for email 

support/services. 

HTTPS POST/REST: 

• Based on both Ease of Implementation and Ease of Maintenance, the cost 

effectiveness of this approach is very attractive. IIS development staff will have a 

very small learning curve which does not require additional third-party tools on 

top of their existing toolset. 

• From development into production, there is no requirement for additional 

hardware, software, or external IT staff (network, data center, etc...) to 

operationalize this approach. The web-based IIS already provides the necessary 

environment and network to move this forward into production. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 62  

SOAP: 

• No license, hardware, software, third party support costs known. 

EHR or Sender Requirements 

Ease of Implementation: The transport layer must be easy to implement for an EHR. 

ebXML: 

• Keys to success: 

o IIS must accept a support role for helping providers install/configure. 

o The install process must be as easy as possible with minimal manual 

steps. 

o Level of technical knowledge at the provider level is a key factor to 

success. 

• Pros: 

o In Wisconsin and Minnesota, the process of installing PHINMS with the 

provider has become very repeatable and manageable over time. Newer 

versions of PHINMS have also helped as the install process is easier. 

o Once actively engaged in the project, providers can usually be ready to 

submit data (queries) within a week. 

o ebXML provides a very extensive set of rules to allow for better 

interoperability. 

• Cons: 

o ebXML is a bit more obscure than web services and providers may 

struggle to work with it. 

o Very few EHR’s are interested in bundling a third-party tool into their EHR. 

• Other notes 

o Still being rolled out to providers. 

o Providers that at one time declined to install PHINMS are now moving to 

implement PHINMS. 

SMTP+S/MIME: 

• Polaris Medical Management EHR Implementation of SMTP+S/MIME fit very 

nicely into their development cycle. No issues were encountered and it was 

described as simple and easy. 

• From an EHR perspective, if the EHR is hosted at the practice: 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 63  

o Email servers aren’t typically tied to EHR platform which creates an 

interface problem between the EHR and the email server. 

· EHR vendors are starting to build exchange capabilities into the 

EHR to mitigate this. Usually based on the IHE XDR profile or a 

proprietary exchange. 

o Often from an EHR perspective, it is easier to stay within your own 

platform and product for sending than potentially interfacing with an 

unknown server such as email or a HISP. 

• Integrating into an EHR may take a similar amount of effort as an HTTPS model. 

HTTPS POST/REST: 

• IIS perspective: 

o From the IIS perspective, success largely depends upon the technical 

expertise at the provider setting. Most IIS provide some level of an 

Implementation Guide, Guidelines, sample code, and varying level of 

support in implementing. 

o This is usually performed with minimal questions due to the 

straightforward approach of HTTPS POST and the familiarity with HTTP at 

the provider level. 

• IHS Perspective: 

o Considered a “medium” for easiness compared to other technical tasks 

given to local technical staff. The technology is easy for those familiar 

with it, but the local IT staff isn’t always familiar with HTTPS POST at this 

level of detail. 

o Usually successful within a couple weeks. 

• The other key driver to ease of implementation is how the EHR is supported. 

o If the provider has an “EHR-Hosted” solution it is very simple and 

straightforward, as the EHR vendor is responsible for the implementation 

o If the provider has the EHR installed locally, it often takes a bit longer as 

the IIS is working directly with the provider with a limited IT skill set. 

• REST may add some complexity over simple HTTPS POST. 

• Making the step from HTTPS POST up to a full RESTful architecture would be 

very manageable. 

SOAP: 

• Pros: 

o The tooling across the variety of languages makes SOAP easy to work 

with. 

o Exposing the WSDL at the endpoint makes for an easier implementation. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 64  

o SOAP provides the ability for IIS to easily provide sample code in various 

languages aids in EHR adoption and development time. 

o Wisconsin is working on a small bundled client which can be installed with 

minimal effort to eliminate provider technical resources from having to 

learn web services. 

• Cons: 

o Private Key installation into a key store can sometimes be difficult due to 

OS access issues. Local technical resources are not always familiar with 

these issues. 

• Other notes: 

o Timeline for the EHR in NYC is currently 3-6 months, but that timeframe is 

being condensed as the process is refined. 

o Oregon, Wisconsin, and NYC all provide some level of documentation to 

the provider to specify how to interface with their IIS. 

o Dependency on the EHR to become actively engaged often drives the 

timeline. 

• Once an EHR has it implemented, rolling it out to multiple providers become 

easier. 

Ease of Maintenance: The transport layer must be easy to maintain for an EHR. 

ebXML: 

• Pros: 

o When PHINMS is running, it is very solid. Providers rarely have to call in 

for support issues. 

• Cons: 

o Older versions of PHINMS have an issue with limited package size. 

o Sending and Receiving directories have caused confusion at the provider 

level. 

o In Wisconsin, if they have to perform maintenance and shutdown 

PHINMS, they must inform their “senders” to restart their instances for 

future successful communication. 

o Sometimes providers are unaware their PHINMS install has stopped 

sending data. The IIS help desk must reach out to the provider for a 

restart. 

o Providers sometimes run into PHINMS counter issues requiring technical 

support by the IIS to aid in properly setting their counter. 

o Providers and EHR’s can struggle interfacing with PHINMS. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 65  

• Native ebXML could eliminate many of the cons listed above, but would require 

much deeper ebXML knowledge on the provider side which is known to be 

limited. 

SMTP+S/MIME: 

• Most will likely be implemented with a HISP who will be managing support for the 

provider. 

o While this is not necessarily a problem, it does add an extra layer of 

support the providers have to consider when dealing with maintenance 

issues and where the support comes from (EHR, HISP, or IIS). 

HTTPS POST/REST: 

• IHS Perspective: 

o Once implemented, it is very solid and issues rarely occur. 

o If an issue does occur it is not immediately clear where the problem is 

from the provider perspective, but this is likely an issue with all transports. 

· A better defined flow or process would help this. 

· Once the problem is properly identified, fixing the problem is very 

easy. 

• The IIS rarely sees problem with the transport itself. More times than not the 

issue with the content (data). 

SOAP: 

• From the sender perspective, the largest hurdle is certificate management and 

occasional TLS issues related to the certificate or OS access issues. 

• From a transport perspective, very minimal issues occur once the transport is 

implemented and operational. 

Scalable: The transport layer must be able to efficiently handle increases in the number 

of users, patients, and vaccines in the EHR system. 

ebXML: 

• It has proven to be scalable in Wisconsin, but EHR’s have significant work in 

interfacing with PHINMS. 

• Native ebXML has no known scalability issues. 

SMTP+S/MIME:
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 66  

• There are no known scalability issues from a transport perspective. 

HTTPS POST/REST: 

• There are no known limitations. 

• It transports 4-5 Mb of HL7 data per day from Large IHS provider in Arizona. 

SOAP: 

• No scalability issues from the senders point of view. SOAP scales nicely in the 

EHR setting. 

• In New York City, one of the large providers has found a way to parallelize their 

submissions to the IIS. 

Ease of Use: The transport layer must provide effectiveness, efficiency, and 

satisfaction with which the intended users can achieve their tasks in the intended 

context of product use. 

ebXML: 

• Development ease of use may be difficult for the EHR or provider side to tie 

request and response together. 

• Once installed, maintenance activities are easy for the provider. 

SMTP+S/MIME:

• Plenty of toolkits are available to support the use of SMTP+S/MIME. 

• Direct Project has reference implementations available for developers. 

• SMTP+S/MIME plays well in system-to-system sending and receiving for 

asynchronous processing. 

• SMTP+S/MIME do not play well in synchronous query/response or synchronous 

unsolicited data submissions. 

HTTPS POST/REST: 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 67  

• Both live interactions with a human invoking a call to the IIS (seamless to the 

user) and system-to-system interactions are a natural fit for the EHR and support 

all of the HL7 use cases. 

• Similar to the IIS, the same tools can be used by the EHR to develop and support 

HTTPs POST. 

SOAP: 

• Rich Toolsets exist for most any language which makes development easy to 

work with. 

• The nature of this protocol can be implemented in a workflow agnostic manner 

and made very seamless to the end user. 

• SOAP has a very repeatable implementation process for the EHR. 

Performance: The transport layer must provide a framework to achieve service quality 

to the user from the start to the finish of a given task. However, it must not degrade 

other system services to accomplish its task. 

ebXML: 

• ebXML has no known performance issues. ebXML’s underlying transport is 

HTTPS. 

• Using PHINMS it is known to be slower for the full trip due to the EHR’s 

requirement to interface with PHINMS over native ebXML. 

SMTP+S/MIME:

• There are no known performance issues. 

HTTPS POST/REST: 

• There are no known limitations. 

SOAP: 

• SOAP is a very thin client. No additional installation is required outside of what 

the EHR already provides. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 68  

• SOAP has a natural fit with EHRs. 

• There are no known performance issues. 

Cost Effective: The transport layer must be as cost effective as possible for the EHR. 

ebXML: 

• The only cost in Wisconsin and Minnesota for the provider is the human time to 

install the sender. 

SMTP+S/MIME:

• Costs would be developer resources for implementation. Minimal on-going costs 

would be similar to other transport models. 

HTTPS POST/REST: 

• There are no known barriers. There are both open source and privately licensed 

products. This could be entirely implemented with open source tools. 

SOAP: 

• The only cost is development cost. 

• Some IIS may supply a certificate. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 69  

Appendix F: Known Global Issues 

In considering the selection of a top choice for a transport protocol, the team listed and 

discussed a number of factors that are common to all transport layer protocols. Some 

were locally variable issues (e.g., laws), some were addressed through implementation 

and configuration decisions (e.g., Certificates), and some will need to be addressed by 

each site in the design of their systems and environment. Because these issues applied 

to all protocols, the panel considered them out of scope for conducting their evaluation 

and comparison of the protocols. In no particular order, these issues include: 

• IIS support for provider implementations 

• EHR support for multiple transport options 

• Distributed Denial of Service attacks (DDoS) 

• Certificate Management 

• Community Policies and Laws 

• Integration Engineering 

• Demographic Matching and Forecasting 

IIS support for provider implementations 

For any IIS, the broader community of provider participants will likely present a 

challenge in terms of the numbers and types of transport that will require support. We 

recognize that the path to recommending a single transport standard will not suddenly 

make all the others go away - expertise and support for existing and currently 

implemented transport mechanisms will be needed for many months ahead (and 

possibly longer in some jurisdictions). New development should take advantage of the 

emerging standard, so we should see an asymptotic curtailing of legacy support in the 

long term. 

EHR support for multiple transport options

with regard to IIS partners. In 

Certificate Management 

The same challenge will face the EHR vendor community, 

a sense, it may be an even broader problem for the EHR vendors, as they will need to 

meet the transport needs of diverse IIS systems across states, HIEs, etc. 

Any of the candidate technologies that rely on X.509 certificates (or similar) must 

address a number of challenges common to this method: 

The simple numbers problem - As the number of sites grows, the sheer number of 

certificates under management grows as well - along with all the concomitant problems. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 70  

ation Lists for revoked certificates becomes more 

P address, which invalidates the certificate. Even at a fixed error 

For sites lacking an automated workflow tool for this purpose, this can become a 

significant amount of work. 

The CRL problem - As the number of certificates under management grows, the task of 

checking the Certificate Revoc

arduous, and must become more frequent. This is exacerbated by the likelihood that 

the overall community will come to use certificates from a growing number of Certificate 

Authorities as the practice matures, so multiple CRLs must be checked. 

The total cost of operation - Most certificates are non-free, so the overall cost to the 

participating population continues to increase as the number of certificates in use 

increases. 

Error rate - Common certificate errors include expiration and failure to update when 

switching to a new I

rate, as the number of players increases, the amount of time spent in troubleshooting 

and resolving these and other problems will continue to grow. 

Community Policies and Laws

Based on experiences across the

state policies or laws, will introduce a set 

 team, it is very clear those local rules, whether city or 

of potential challenges for which each site 

must adapt. This is most evident in the areas of privacy and security, but also in records 

retention, audit requirements, separation of duties, and many other factors. These are 

not really addressed by the recommendation of a single transport solution. 

Integration Engineering

For any transport metho

engineering' problem - some amount of cust

d, most sites will have a local version of the 'last mile 

om development, configuration, or tooling 

will likely be needed to fully integrate the messaging transport with the IIS proper. 

Demographic Matching and Forecasting

This is nominally a special case of the 'lo

address the issue of validating patient and pr

cal rules' problem - each site will need to 

ovider identities for records matching, 

especially in jurisdictions lacking a single or central master patient index. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 71  

Appendix G: Technology Recommendation Development Workgroups

Project Background

Developer: 

• Deborah Rochat, Oregon ALERT IIS 

Collaborators: 

• Michael Berry, HLN Consulting, LLC 

• George Cole, Allscripts 

• Cecile Town, Indian Health Service (IHS) 

Acknowledgement of Other Transport Layers

Developers: 

• Arien Malec, NHIN Direct 

• Gautam Kesarinath, CDC Public Health Informatics and Technology Program 

Office (PHITPO) 

• Michael Berry, HLN Consulting, LLC 

Collaborators: 

• Tom Maerz, Wisconsin Immunization Registry (WIR) 

• Ben Martinez, New Mexico Statewide Immunization Information System 

(NMSIIS) 

Justification for SOAP Recommendation

Developer: 

• Deborah Rochat, Oregon ALERT IIS 

Collaborators: 

• Marcelo Caldas, CDC Public Health Informatics and Technology Program Office 

(PHITPO) 

• Shane Speciale, Avanza Systems 

• Concetto “Frank” Caniglia, American Immunization Registry Association 

(AIRA) 

• Nathan Bunker, Dandelion Software & Research, LLC 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 72  

• Josh Friedman, Hewlett Packard (HP) 

Impacts

Developers: 

• George Cole, Allscripts 

• Angel Aponte, New York Citywide Immunization Registry (CIR) 

Collaborators: 

• Emily Emerson, Minnesota Immunization Information Connection (MIIC) 

• Bob Barker, Electronic Health Record Association (EHRA) 

Known Global Issues

Developer: 

• Paul Groll, Michigan Care Improvement Registry (MCIR) 

Collaborators: 

• Purvesh Shah, NextGen Healthcare 

• David Rose, Scientific Technologies Corporation (STC) 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 73  

Appendix H: Definitions

Asynchronous Response: As it relates to this panel, the transport layer should allow 

for the receiving system to acknowledge receipt of the payload and process the payload 

on its own schedule. The sender may check back at a later time for a response 

payload, or the receiver may initiate a response (reply) to the sender with the response 

payload. 

Authentication: As it relates to this panel, this is defined to be server-to-server 

authentication. This recommendation should be successful regardless of the payload 

being sent. Today our goal is HL7, but it is very probable something other than HL7 will 

be transported in the future. 

Health System: As it relates to this panel, a health system is the structured and 

interrelated set of all actors and institutions contributing to health improvement. 

Payload Size: As it relates to this panel, payload size refers to the message size in 

support of large batches of data. 

Receiver: As it relates to this panel, the receiver is any health system accepting receipt 

of immunization related messages for processing and possible response back to the 

sender. 

Reliable Transmission: As it relates to this panel, reliable transmission will be defined 

as the concept of communicating messages across an unreliable infrastructure whilst 

being able to make certain guarantees about the successful transmission of the 

message and appropriate handling of faulty and/or unsuccessful transmissions. 

Secure Transmission: As it relates to this panel, secure transmission will be defined 

as the secure method by which payload will be transported from system to system. 

Sender: As it relates to this panel, the sender can be any health system initiating a 

transmission of immunization related messages. 

Synchronous Response: As it relates to this panel, the transport layer should allow for 

the receiving system to return response(s) immediately. 

Transport Methodology: As it relates to this panel, Transport Methodology refers to 

the transport protocol and the application of that transport protocol. It does not refer to 

a software package or product that implements such technology. 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 74  

Appendix I: Related Background Reading Materials 

General 

• HLN Guide to Immunization-related Electronic Data Exchange

• Common Framework for Private and Secure Information Exchange

• Wikipedia: Health information exchange

• eHealth Initiative

• Wikipedia: OSI model

• Wikipedia: Internet Protocol Suite 

• IHS Interface Guide (pdf)

• AIRA IIS Transport Layer Review (pdf)

• Wikipedia: Authentication

• Wikipedia: Authorization

• Wikipedia: XDS.b Implementation (IDS)

• IHE ITI Technical Framework Supplement XDS-2 (pdf)

• HIMSS News - Standards Corner: Update: The Direct Project

• Wikipedia: Web Service

• RFC 216: Hypertext Transfer Protocol -- HTTP/1.1: (Draft Standard)

• AIRA: Immunization Information Systems: Keeping Pace With Evolving Public Health 

Initiatives

Web Service 

• Wikipedia: Web Services Description Language

• W3C: SOAP Message Transmission Optimization Mechanism

• Wikipedia: SOAP

• W3C: Latest SOAP versions

• W3C: Simple Object Access Protocol (SOAP) 1.1 

• W3C: SOAP Version 1.2 Part 1: Messaging Framework (Second Edition) 

• AIRA: Evaluation of Web Service for Communicating with IIS (pdf)

HTTPS POST/REST 

• Working Together on Data Exchange: A Guide to Indian Health Service (IHS) and State 

Immunization Information System (SIIS) Interfaces

• AIRA: Evaluation of HTTPS POST/REST for Communicating with IIS

• Wikipedia: POST (HTTP)

• Wikipedia: HTTP

• Wikipedia: Representational State Transfer

• What protocol for NHIN Direct? (Blog, Fred Trotter)

ebXML 
EHR‐IIS Interoperability Enhancement Project: Transport Layer Protocol Recommendation

Page | 75  

• PHIN Messaging System

• Rhapsody/PHINMS Interoperability (pdf)

• AIRA: Evaluation of ebXML for Communicating with IIS

• ebXML

• Wikipedia: ebXML

SMTP+S/MIME 

• Wikipedia: Simple Mail Transfer Protocol

• Wikipedia: S/MIME

• The Direct Project

• NHIN Direct - Overview For Consensus

• The Direct Project: Deployment Models

• RFC 821: Simple Mail Transfer Protocol

• RFC 5321: Simple Mail Transfer Protocol (Draft Standard)

• Wikipedia: MIME

• HIT Standards Committee Meeting: November 20, 2010

SFTP and SCP 

• Wikipedia: File Transfer Protocol

• Wikipedia: SSH File Transfer Protocol

• Wikipedia: Secure Copy

• RFC 959: File Transfer Protocol (FTP) (Standard)

• RFC 2228: FTP Security Extensions (Proposed Standard)

• RFC 2428: FTP Extensions for IPv6 and NATs (Proposed Standard)

This document can be found on the CDC website at: 

http://www.cdc.gov/vaccines/programs/iis/downloads/ehr-interop-trans-layer-tech-recs.pdf

Last Reviewed Feb 2016