October 9, 2001

The Secretary of the U.S. Department of Health and Human Services &
National Committee on Vital and Health Statistics
Standards and Security Subcommittee

RE: Uniform Data Standards for Patient Medical Record Information

Honorable Chair and Distinguished Members of the Committee:

The Administrative Simplification provisions of the Health Insurance Portability and Accountability Act (HIPAA) of 1996, section 263, calls for the adoption of uniform data standards for patient medical record information (PMRI). The electronic exchange of that information is of great interest to MedcomSoftä.

Before I explain our experiences with the standards being discussed today I believe a brief explanation of my company will provide a useful context to understand my testimony. MedcomSoft is pioneering the use of intelligent data entry systems and the internet to improve the collection and dissemination of healthcare information, simplify workflows, improve the delivery and quality of patient care, and decrease costs throughout the healthcare industry. The MedcomSoft platform was developed to facilitate the business transactions and the exchange of information between all entities involved in the healthcare industry, which include: providers, suppliers, insurers, payers and regulators, and of course, patients. MedcomSoft systems support the capture, aggregation and secure communication of structured and codified Electronic Patient Records.

MedcomSoft recognizes the imperative of the PMRI initiative to determine comprehensive standards. We have taken steps through the implementation of our system to analyze industry-recognized standards for clinical data capture, drug and lab codes, as well as data transmission and message formats. The task of researching and implementing compatible standards requires enormous resources from any business. As the CEO of MedcomSoft, and as a licensed physician, I am grateful to participate in helping NCVHS take the lead on this issue. The healthcare industry is seeking guidance, and these discussions are an important component.

In order to capture the clinical data MedcomSoft adopted the highly structured Medcin" Nomenclature. We believe it facilitates the appropriate degree of granular detail required for medical documentation standards in a codified format. For data transmission and messaging MedcomSoft adopted and implemented within its Data Engine the ANSI X12 for claims data transmissions, and HL7 standard for other patient related medical transactions.

I appreciate the opportunity to provide comments, and present to you MedcomSoft’s experience in implementing some of the standards being considered today.

HL7

Current & Future implementation

The MedcomSoft Data Engine supports HL7 standards V2.1 to V2.3 with all transaction sets. We are currently in the process of implementing HL7 V-3.

HL7’s earlier versions used informal and ad hoc development methods and lacked plug-and-play functionality. During the development of version 3.0 these were replaced with more formal development methods used in object oriented analysis and design techniques. The use of the Message Development Format (MDF) and the Reference Information Model (RIM) provides an advanced and comprehensive Object Oriented information model for clinical healthcare. The increased specificity of the RIM in version 3.0 will enable greater interoperability between healthcare information systems. However, even with the support of XML in HL7 version 3.0 the problem of semantics in healthcare is not resolved without significant effort. XML is rapidly becoming the data portability standard enabling the exchange of information between many systems. In my opinion it will require several years of hard work to build a semantic foundation for healthcare interoperability which positions HL7 version 3.0 to take advantage of XML.

The HL7 messaging format has become the industry’s defacto standard for communicating patient related clinical information. By electing to use the HL7 format, the MedcomSoft system can communicate with the majority of 3rd party vendors with systems similar to ours, as well as other healthcare participants. The initial implementation was completed within 12 months. The support for higher versions of the standard, as they became available, was completed in two weeks. We anticipate the implementation of version 3 will require a minimum of 18 months due to the newly introduced record structure and the use of XML. MedcomSoft decided to implement version 3 because of it matches our system’s future architecture and flexibility.

Cost

Costs incurred during the development of the standard breakdown into the following areas:

• Education: 20 person days
• Fees: $3,500 membership fee.
• Interface Engine: 3 person years
• Custom Coding: 10 person days / year
• Testing: 20 person days per message set
• Maintenance: 10 person days / year

Advantages

• Simple protocol to implement and understand
• Complete set of messages for application integration
• Wide industry support of messages

Weaknesses

Recognized weaknesses of the HL7 standard:

• The organization does not provide a mechanism for testing, this creates the need to have an actual vendor on the receiving end of the message to check the validity of the transmission. In order to complete any pre testing, the vendor is forced to simulate a second system, which would be sending and receiving messages to and from the Data Engine.
• The openness of user defined segments can lead to much vendor customization. This openness prohibits the integration of systems in a timely and low-cost manner.
• Lack of implementation guides leaves too much room for vendors to develop their own implementation guides that may contradict or avoid requirements that are very specifically defined in the standard. Our experience is that when integrating applications to HL7 interfaces the two systems never communicate perfectly without some customization.
• The more information that is exchanged between systems, the higher the likelihood that the interfaces will not work properly. As these HL7 interfaces increase in their sophistication, the requirement for customization also increases, slowing down implementation times and increasing integration costs.
• Lack of a certification body that provides conformance testing to the standard. Compliance must cover communication processes as well as data types.
• There is a lack of standard codes to ensure the format and content of the transmitted message is comparable and consistent when shared among different systems. While many industry codes have been established within HL7 there is still room to add more. The more data values that are standardized, the more easily data can be exchanged by systems.

Recommendations:

• The committee should support the appointment of an organization that will facilitate the testing and provide the proper mechanics for vendor compliance and certification.
• There should be a very specific but standard implementation guide that is employed by all vendors for each kind of PMRI message.
• The organization should provide a means for testing the implementation of each Transaction Set that the standard supports. An example of this would be a web site for vendors to send messages to and receive validation of the message format.
• Create the mechanics for certification. Certification should be issued to the vendors based on level of conformance to assure that a standard has been implemented according to its implementation guidelines, and that it performs its functions as intended.
• Create one standard format that includes both healthcare terminology standards and message format standards. Standardizing the content of the message facilitates interoperability between systems.
• Message formats should establish minimum and maximum data elements, to promote better integration. With this benchmark in place, and accessible to vendors, interface development will have a common reference point for all vendors.

In conclusion, MedcomSoft recommends that HL7 remains the preferred messaging standard. We believe that significant improvements can be made including the addition of medical terminology and will encourage its universal acceptance by vendors. However, because HL7 does not include a broadly accepted scripting standard the use of additional standard such as NCPDP messaging standard becomes necessary.

NCPDP

The standard that NCPDP is most famous for is "Telecommunication Standard Version 5 Release 1" which has already been named in HIPAA's final rule. This standard deals primarily with direct electronic submission and adjudication of transactions in an on-line, real-time environment and has huge implications for pharmacies. However, the NCPDP "Script Standard”, which was developed for the purpose of transmitting prescription information electronically between prescribers and pharmacists, seems the most relevant NCPDP standard for the purposes of MedcomSoft. It adheres to UN/EDIFACT syntax and utilizes standard EDIFACT and ASC X12 data tables where possible. Currently, the standard addresses the electronic transmission of new prescriptions, prescription refill requests, prescription fill status notifications, and cancellation notifications. Future enhancements, as listed by the NCPDP, may include patient status requests, lab values, diagnosis, disease management protocols, patient drug therapy profiles, DUR alerts, prescription transfers, and formulary recommendations.

The NCPDP version 5.0 standard is very comprehensive and included many extensions covering information such as controlled substances, eligibility, and drug utilization. Previous experience with the conversion of claims adjudication software to incorporate NCPDP 5.0 standard format versus NCPDP 3A standard format required 3,857 hours of development time at an internal cost of $212,570.00. These did not include all new NCPDP 5.0 formats but just those related to claims processing.

It is very apparent under this effort that, for example, NCPDP 5.0 had many data items which duplicate those data items found in the HL7 standard format, particularly as it relates to patient information. These duplicate items are slightly different in each standard. At the time NCPDP 5.0 comprised several hundred data items.

The committee should seek to reduce duplication among standards. An effort should be made to eliminate duplication in NCPDP of any HL7 standard, but still provide NCPDP as an extension to already existing HL7 data standards.

On behalf of MedcomSoft and Medical Record Solutions, we thank you for the opportunity to work with you on this much needed and important initiative.

Sincerely,

Sami Aita, M.D.
Chairman and Chief Executive Officer
MedcomSoft Inc.
1200 Eglinton Ave. E. #900
Toronto, Ont. Canada M3C 1H9
Tel: (416) 443-8788 x232
Fax: (416) 492-9192
Email: samiaita@MedcomSoft.com