Using SAS to Handle HL7 Messages in A Health Information ... · • Support the data query Web application, run dynamic data queries upon user’s request, ... ” simply displays

1

Using SAS® to Handle HL7 Messages in A Health Information Exchange Enxu Zhao, Kathryn J. Schmit, Linh H. Le

New York State Department of Health, Albany, NY

ABSTRACT This paper will discuss issues regarding the design of an automated data processing system for the New York State Department of Health’s (NYSDOH) Health Information Exchange (HIE). Base SAS and SAS/ACCESS are used to access HL7 data from Oracle databases, generate minimum datasets (MDS), and initiate data transmis-sion from NYSDOH to the Centers for Disease Control and Prevention (CDC) and local health departments. SAS/INTRNET is used for data analysis and visualization. Some of the challenges encountered during system development, such as SQL queries, X commands, ODS and HTML Web posts, will also be discussed.

INTRODUCTION The Health Information Exchange (HIE) is a project sponsored by the CDC to establish an operational national health surveillance system. Its plans include intensive data gathering from medical facilities by state and local health departments, which will then send reports to a CDC-owned data warehouse. A networked system will al-low for bi-directional information flow among public health agencies and clinical healthcare providers. The New York State Department of Health (NYSDOH) functions as one of the nodes in this network. The success of the project will depend on the ability of participants to use standardized messaging formats in an automated data processing system.

The purpose of this paper is to present the system design for automated HIE data processing using SAS as core software. This paper will focus on the SAS techniques for automated data processing, analysis, and visualization. Some obstacles encountered during the system development will also be addressed.

HL7 MESSAGES IN HIE The HL7 protocol, developed by the Health Level 7 Organization, is the most widely implemented standard for healthcare information in the world. It consists of a standardized grammar and vocabulary that allow clinical data to be shared among all healthcare systems. HL7 Version 2.5 is currently used as the standard for data exchange in HIE in New York State (NYS). The following is a sample of a single HL7 v2.5 message.

Message files may contain from one to tens of thousands of individual messages. Each message is in text for-matting, with segments containing data relating to a specific topic (e.g., PID=patient identification) carried in fields and subfields separated by standard delimiters. Large numbers of these HL7 messages are sent from Regional Health Information Organizations (RHIOs) to NYSDOH every day. Our task has been to set up a data processing system that can access these messages from an Oracle database, integrate the information into SAS datasets, and transmit data automatically for various uses.

THE NEW YORK STATE (NYS) HIE SYSTEM Figure 2 shows the structure of the HIE system in NYS. RHIOs serve as the data integration nodes. They first convert the data collected from medical facilities to HL7 v2.5 messages following the implementation guide and then transfer these messages to NYSDOH via PhinMS. These incoming data will be parsed by Rhapsody and put into an Oracle database several times a day. As one of the state-level nodes in a national HIE network,

Figure 1. HL7 Message

MSH|^~\&|ADT|HOSP1|RHIO1|NYSDOH|20090619104426||ADT^A08||P|2.5|||||||||BS1.0^HITSP^^ PID|||123456789AAA^^^HOSP1||||194201|F|||^^^NY^10309|||||||123456789BBB PV1||E|||||||||||||||||123456789CCC|||||||||||||||||||||||||200906190707000000| PV2|||^DIFFICULTY BREATHING OBX|1|NM|AGE||66|years DG1|1|FF|^PNEUMONIA COPD EXACERBATION^FF||200906191044260000|A

Applications Big & SmallNESUG 2009

2

NYSDOH first integrates these data with other surveillance data, then generates standardized datasets to share with CDC and local health departments.

Figure 2. NYS HIE System

NEW YORK STATE’S HIE DATA PROCESSING SYSTEM The NYSDOH HIE data processing system includes the following components:

Databases – repositories for data collected from RHIOs and NYS surveillance systems

SAS Server/SAS INTRNET Server – the core part of the data system, which has the following functions:

• Access and query the databases, extract information, generate minimum datasets (MDS)

• Store the reporting data in reporting data repository

• Initialize data transmission to the CDC and the New York City Department of Health and Mental Hygiene (NYCDOHMH)

• Initialize automated distribution of SAS performance reports via email to system administrator and project partners

• Support the data query Web application, run dynamic data queries upon user’s request, generate statisti-cal reports and send them to users’ Web browsers via Web application server

Reporting Data Repository – store the reporting datasets and share the data with NYSDOH programs

Web Application Server – host the dynamic data query system interface

• Handle the requests for data reports from users

• Invoke SAS INTRNET server to start a data query process

• Collect the SAS output and send it back to user’s Web browser

Email Server – in response to email sending request from SAS Server, distribute SAS performance reports to system administrator and project partners


3

Figure 3. NYS HIE Data Processing System

AUTOMATING SAS PROGRAMS In the data processing system, all the SAS programs are running at scheduled times–some once a day, others several times a day. There are several options for scheduling SAS jobs to run at a set time or on a repetitive ba-sis. Windows Task Scheduler is the most popular and handy way to accomplish this task. It comes with all Windows 95 operating systems or later versions.

To schedule a SAS job, a desktop user would click path “Start –> All Programs –> Accessories –> System Tools –> Scheduled Tasks” and then double-click on the “Add Scheduled Task” icon. At this point the Task Wizard ap-pears and you would click “Next” and choose “SAS 9.1(English)” from the scroll-down box. The user can select the frequency at which the task is supposed to be performed; after clicking “Next,” a new screen will open that allows you to provide additional parameters for date and time when the job will be performed.


4

On the next screen, you will be asked to provide a username and password. Make sure the account you provide has sufficient authorization to perform the scheduled task, otherwise your job will fail to execute. On the final screen, there is a check box labeled “Open advanced properties for this task when I click Finish.” Check this box and it will direct you to a screen that allows you to specify the path and name of your SAS program. In the Run box, type in a space after all the text that is already there, followed by –sysin, then another space, and the com-plete path to your SAS program inside quotes. For example:

-sysin 'D:\HIE\data_processing.sas'

Click OK to close the window and add an icon for the job in the Scheduled Tasks folder. The default name for SAS jobs is SAS 9.1(English); you must rename it to avoid confusion, especially when you have more than one scheduled SAS jobs.

ACCESSING A DATABASE USING DATABASE STORED PROCEDURE Before you can connect to an Oracle/Sybase database by SAS/ACCESS, make sure that you have database cli-ent software installed on your PC and that the database information has been correctly configured. There are two basic methods of accessing data from Oracle/Sybase database: the LIBNAME method and the SQL Pass-Through method. We will take Oracle as an example, but Sybase is similar.

LIBNAME method connects to Oracle database by defining “Oracle” as the engine in the LIBNAME statement, as follows:

libname myoralib oracle user='myuid' password='mypassword' path='mydbpath';

For example:

libname oraprd03 oracle user='hie_owner' password='dragon' path='ora_f68vrec';

in this case, the path points to the connection as set up in the Oracle Client software and is the system ID (SID) used for the Oracle database.

SQL Pass-Through method connects directly to the Oracle instance. The general format is:

proc sql; connect to oracle (user='myuid' password='mypassword' path='mydbpath') [sql statement] disconnect from oracle; quit;

As an example:

proc sql; connect to oracle (user='hie_owner' password='dragon' path='ora_f68vrec'); %put &sqlxmsg;

create table hie.hl7 as select * from connection to oracle

(select * from hl7_message); %put &sqlxmsg;

disconnect from oracle; quit; run;

In the above example, the statement “%put &sqlxmsg;” simply displays any DBMS error message in the SAS log.

These two methods can handle database queries in most cases, but when detailed information about the data table is not available for database maintenance or data security reasons, an alternative is to query the database by using a database stored procedure provided by the database administrator. In this case, the LIBNAME method cannot accomplish the task. The only option is to use the SQL Path-Through method to access the data-base.

The following is an example of how to use a database stored procedure to query a database via the SQL Path-Through method.


5

proc sql; connect to oracle (user='hie_owner' password='dragon' path='ora_f68vrec'); %put &sqlxmsg;

create table hie.hl7 as select * from connection to oracle (spvs_get_data 'hie_owner',92,'*');

%put &sqlxmsg; disconnect from oracle;

quit; run;

spvs_get_data is a stored procedure in the Oracle database, which is programmed by database administrator. 'hie_owner', 92 and '*' are parameters of the stored procedure, standing for username, data table ID, and columns in the selected data table, respectively.

HL7 MESSAGE PROCESSING After HL7 messages are received from RHIOs via PhinMS, they are parsed into a file table, message table, and segment-field tables by Rhapsody. Then the parsed data are saved in hierarchical Oracle data tables linked with unique file sequence ID and message sequence ID. As can be seen in Figure 1, many fields within the HL7 mes-sage are empty; by parsing the data into separate fields, we can store only those fields containing data required for the HIE project, which saves a great deal of database space. The following figure diagrams the hierarchical data table structure used in our database:

Figure 4. HL7 Data Hierarchy Table Structure

In order to process the data, five different SAS jobs are scheduled to run: data fetching, data combining, data generation, data transmission, and performance report distribution.

STEP 1 – DATA FETCHING This step is scheduled to run every four hours. It will extract the unprocessed HL7 messages from Oracle, file by file. Only one file is processed in each loop. The program will keep running until all files in the database have been processed or until a maximum running time of three hours has been reached. The maximum running time is set to avoid the data access conflict between multiple thread programs.

The SAS codes for setting the maximum running time and controlling the program flow are as follows:

%macro fetch; %let start_time = %sysfunc(datetime());


6

%begin: %let current_time=%sysfunc(datetime()); %if "%sysevalf(&current_time-&start_time-10800)">"0"

%then %goto finish;

proc sql; select count(*) into: f_num from oraprd03.message_file where file_process_datetime is not null and sas_process_datetime is null

; quit;

%if &f_num=0 %then %goto finish;

data _null_;

set oraprd03.message_file(obs=1); where file_process_datetime is not null and

sas_process_datetime is null; call symputx("f_id",file_seq_id);

run;

[more sql procedures]

proc sql; update oraprd03.message_file set sas_process_datetime="%sysfunc(datetime(),datetime23.3)"dt where file_seq_id=&f_id ;

quit;

%goto begin; %finish:

%mend fetch;

A few notes on the above example:

• file_process_datetime and sas_process_datetime are the processing datetimes of com-pleted Rhapsody and SAS programs, respectively. A null value means the file is not processed.

• file_seq_id is the unique identifier assigned sequentially to files as they are received

This step will create tables named for each segment in the HL7 messages and save them to a specific directory in the data repository. These tables will contain all the data from specified locations of the segment (the data we want to read in); if no information is contained in one of these locations (e.g., a diagnosis code in a DG1 seg-ment), the data cell for that location is null. All these datasets follow a predefined name convention:

[RHIO’s Name]_[Segment Type]_[File_Seq_ID]_[File_Process_Date].sas7bdat

For example, dataset “RHIO1_MSH_9168_20JUN09.sas7bdat” contains all MSH segments in the file with se-quence ID 9168. This file was sent from RHIO1 and processed on June 20, 2009.

STEP 2 – DATA COMBINING At the end of each day, we create daily segment datasets, reporting datasets, and minimum datasets (the data elements required to perform the functions as required for the project, such as disease surveillance). First, that day’s segment tables from each RHIO, created in the previous step, are merged so that each row of the data ta-ble contains all the information submitted from a single HL7 message. The main challenge is that the number and names of datasets created vary every day. In order to combine these datasets together, the list of dataset names for each RHIO and segment type must be converted to macro variables.


7

PROC DATASETS is used to create a variable that contains all the datasets names in a directory. The SYM-PUTX() function is used in a data step to pass all the datasets’ names to a series of macro variables.

proc datasets memtype=data lib=hie; contents data=hie._all_ out=out.all_ds;

run; quit;

proc sort data=out.all_ds out=ds_names nodupkey; by memname;

run;

data _null_; set ds_names end=last; call symputx('dsname'||left(_n_), memname); if last then call symputx('cnt',_n_);

run;

A few notes on the above codes: • When the _ALL_ keyword is specified, a list of all datasets in the directory is provided. • all_ds should be put into a different directory, where the group of analysis datasets is; otherwise, SAS

will consider the all_ds dataset as one of the segment tables. • The all_ds dataset must be a permanent dataset, otherwise PROC DATASETS automatically puts it into

the same directory with the analysis datasets. • PROC SORT is used to de-duplicate the variable MEMNAME in the dataset out.all_ds since PROC

DATASETS creates contents by variable name, not by MEMNAME. • A series of macro variables are created: cnt is the total number of datasets in the directory, and

dsname1–dsnameN are the names of each dataset.

After the macro variables have been created, all the datasets in the directory are combined by using a macro loop within a macro program.

%macro combine(rhio,seg,date) data seg.&rhio._&seg._&date;

set %do i = 1 %to &cnt;

hie.&&dsname&i %end; ;

run; %mend combine; %combine(RHIO1,msh,20jun09)

Actually, only a list of the dataset names is needed in our case. We do not need to analyze any single dataset. There is a simpler way to do the job, as shown in the following SAS codes:

proc sql; select unique memname into: ds_list separated by " hie." from out.all_ds ; quit;

data seg.RHIO1_msh_20jun09; set hie.&ds_list; run;

STEP 3 – DATA GENERATION This step is also scheduled to run at the end of day. The reporting datasets and minimum datasets are generated in this step following the data dictionary. One main process in this step is to extract the proper fields (as defined in the project’s implementation guide) from the segment table generated in step 2. Fields that include only one subfield can be easily converted to variables in the reporting or minimum datasets. But fields that include more than one subfield (e.g., the eleventh field in the PID segment, which contains both state and ZIP Code of patient

Dataset Name Macro Variable

RHIO1_MSH_9168_18JUN09 dsname1



…… ……


8

residence – see Figure 1) must be parsed. The SCAN() function is used to select a substring from a character string. It works well when all the subfields have nonmissing values, but when there are missing values for some subfields, consecutive delimiters will appear in the character string. For example: “^^^NY^10309“.

If you are using SAS 9.2, this is not a concern at all, since new arguments have been added to the SCAN() func-tion in SAS 9.2 to deal with the consecutive delimiters. But if, like most of us, you are using SAS 9.1 or an older version, extra action is required to deal with this problem.

If the following SAS codes are submitted, the variable zip should have character value “10309”.

data a; input address : $11.; datalines; ^^^NY^10309 ;

run; data b; set a; zip = scan(address,5); run;

But the actual value for zip in this code would be missing. This happens because the SCAN() function, which substrings the fifth “word” in the string, ignores all the delimiters before the first non-missing character and treats all consecutive delimiters as one. So if we want to get “10309”, “2” has to be the second argument. This is very inconvenient because HL7 is a very strict standard and the exact position of a data element defines its meaning.

The following SAS macro function is written to deal this problem:

%macro betterscan(var,ps,dlm,newvar,varleng); array &newvar.t(&ps) $&varleng; tmp = &var; do i = 1 to hbound(&newvar.t); pos = index(tmp,"&dlm"); if pos = 0 then do; &newvar.t(i) = tmp; tmp = ''; end; else if pos = 1 then do; &newvar.t(i) = ''; tmp = substr(tmp,2); end; else do; &newvar.t(i) = substr(tmp,1,pos-1); tmp = substr(tmp,pos+1); end; end; &newvar = left(trim(&newvar.t&ps)); drop pos i tmp &newvar.t1 %if &ps > 1 %then - &newvar.t&ps;; %mend betterscan;

The arguments of this function are:

var – character string to select substring from

ps – position of the substring in the character string you want to select from

dlm – substring delimiter

newvar – the variable name for the selected substring

varleng – the length of newvar; if you are not sure about this, use a large value to be safe

The following is an example of how this macro program can be used in a data step.


9

data b; set a;

%betterscan(address,4,^,state,8) %betterscan(address,5,^,zip,8) run;

The function will correctly choose the fourth and fifth substring (“NY” and “10309”) from address and assign them to variables state and zip, respectively.

STEP 4 – DATA TRANSMISSION PhinMS is used to transmit the minimum datasets to NYCDOHMH everyday at midnight. It will automatically send out the files that are dropped in the outgoing folder for specific destination. SAS can easily write the gener-ated SAS datasets to any directory identified by a LIBNAME statement. But, to complicate matters, we must minimize the size of (or “zip”) the datasets before dropping them to the outgoing folder of PhinMS. Normally there is maximum size limit for files sent via PhinMS for security reasons. The transmission will fail if the file size is over the limit. Zipping SAS datasets can reduce the file size significantly, since most the variables in the dataset are character. This can also reduce the transmission time and save the system resources.

The X command is used to zip the outgoing SAS datasets automatically. The following is an example:

X call "C:\Program Files\ESTsoft\ALZip\ALZip.exe" –a "D:\HIE_DATA\RHIO1\MDS\RHIO1_census_mds_&sysdate..sas7bdat" "C:\PhinMS_drops\CDCHIE\outgoing\RHIO1_census_mds_&sysdate..zip";

In the above example, &sysdate is the system macro variable that resolves to the current date when the program runs. ALZip is free zip software by ESTsoft that provides a lot of command line options. Option –a is for Ar-chive, and –x is Extract, etc. The command call is put there so that the X command can be used together with macro variables.

The system option NOXWAIT must be specified, otherwise the default option XWAIT will take effect and keep the DOS shell open after the command is executed, in which case DOS has to be closed manually. If a SAS job is a scheduled task, the whole program will stop at the X command, which will cause the automated job to fail.

STEP 5 – PERFORMANCE REPORT DISTRIBUTION The SAS jobs are scheduled to run without requiring any staff to take action. But what if the programs are not executed successfully for some reason—as when a server is down? To ensure that we give immediate attention to problems as they arise, we created automatically scheduled status reports and email notifications as a means of monitoring program performance.

SAS electronic mail facilities can be used to fulfill the desired functions. A SAS job can be scheduled to run every day to send an email to the system administrator (and other interested parties) about the system performance. It can also attach all SAS logs and performance reports (generated by other SAS programs).

Before SAS can send emails, a few system options have to be specified in the SAS configuration file:

• -EMAILSYS MAPI VIM SMTP determines which application interface to use (MAPI or VIM), or indicates direct communication with the SMTP server (SMTP).

• -EMAILID "user" may be requested by your email software when you specify MAPI or VIM under the EMAILSYS option.

• -EMAILPW "password" may be requested by your email software when you specify MAPI or VIM under the EMAILSYS option.

• -EMAILHOST "SMTP-server-domain-name" specifies the exact domain name for your SMTP server.

• -EMAILPORT port-number specifies the physical port number used for SMTP communication. Gener-ally, default value 25 is used.

The last two options are only needed when using SMTP. All these options must be specified in the SAS configu-ration file (SASV9.CFG) or in the SAS start-up command. The configuration file can be found in the directory C:\Program Files\SAS\SAS 9.1\nls\en.

SAS can send out email in several ways. Our programs contain FILENAME and FILE statements in a data step. The example codes are as follows:


10

filename hie email subject="HIE SAS Performance Report - &sysdate" from="[email protected]" to= "[email protected]" cc= "[email protected] [email protected]" attach= "D:\HIE_REPORT\SAS_Performance_Report_&sysdate..html"; data _null_;

file hie; put "Here is the SAS Performance Report for &sysdate.."; run;

This is only a generic example, and it could be made much more complex to fulfill more functionalities. For ex-ample, in our project, we scanned all the SAS log files. If any error or warning message is found, SAS will send an email to the appropriate administrator (as determined by the error message type). We also have generated a daily statistical report that contains detailed information about data volume, data transmission times, data proc-essing time, and system resource usage; this is also sent to the system administrator via email. We will not dis-cuss these in detail in this paper.

DATA ANALYSIS/VISUALIZATION The steps described above created a data repository of information about healthcare encounters in hospitals served by our RHIO partners in the HIE. From this database data may be drawn for investigations or reports by personnel in the NYSDOH and NYCDOHMH. The procedure for making a request for data is as follows:

• The user issues a data analysis request through a Web service interface

• The Web Server invokes the Application Server to start a SAS INTRNET process

• The database is queried and the report is generated by using the HTTP post information

• The report is sent to the user’s browser through the Application Server

DATA QUERY USER WEB SERVICE INTERFACE The data query services are currently under development. The example below reflects our plan for data visuali-zation for HIE but uses fake data for illustration only.

The Application Dispatcher of SAS INTRNET includes the Application Server and the Application Broker, and it provides a CGI gateway (namely, the Application Broker) between a Web browser and SAS. This gateway en-ables programmers to build dynamic applications that can access the power of SAS (the Application Server) from their Web browsers. The programmers need be concerned only with the details of the reports the SAS program is to generate. The following is an example link that a developer may use in the Web browser to invoke a SAS INTRNET process via the Application dispatcher:

www.hie.com/cgi-bin/broker.exe?_PROGRAM=sasweb.DynamicReport.sas&_SERVICE=default

Users can request a data analysis report via a Web service interface, which is developed with Servlet/JSP. This Web service invokes the SAS INTRNET process and passes the query parameters by HTTP post method. Each user is identified by the login userID/password so that only those with the appropriate access level are allowed to view the data. Figure 5 shows the last page of a sample data query Web service interface.

After the user clicks the Submit button, a data query request is sent to the Application Server with all the parame-ters that user has selected. The following is part of the HTTP post symbols. The programmer can specify the parameter _debug = 1 to display the field values passed from the Application Broker to the Application Server. Also, _debug = 128 returns a SAS log for the requested program as HTML, and _debug = 2 displays the Applica-tion Broker version number and elapsed time after each run. If all this information is to be displayed, _debug = 131 (1+128+2) can be specified.

Symbols passed to SAS #symbols: 40 "_SRVNAME" = "hie01" "_SRVPORT" = "80" "_REQMETH" = "POST"


11

"_RMTHOST" = "" "_RMTADDR" = "000.000.00.00" "_RMTUSER" = "" "_HTCOOK" = "" "_HTUA" = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" "_mrvimg" = "/sasweb/IntrNet9/MRV/images" "_grfaplt" = "/sasweb/graph/graphapp.jar" "_grafloc" = "/sasweb/graph" "_PROGRAM" = "sasweb.DynamicReport.sas" "_SERVICE" = "default" "_DEBUG" = "131" "_VERSION" = "9.1.3-4" "_URL" = "/cgi-bin/broker.exe" "_ADMIN" = "Enxu Zhao" "_ADMAIL" = "[email protected]" "_DEBUGMASK" = "-1" "_SERVER" = "hie01" "_PORT" = "5001" "rescnty2s" = "1" "agegrps" = "0"

……

In the SAS program, the parameters passed from the HTTP post method are retrieved by using the macro func-tion %SUPERQ().

%let agegrps = %superq(agegrps); %let rescnty2s = %superq(rescnty2s); ……

Figure 5. Model of HIE Data Query System Web Service Interface


12

DYNAMIC REPORT GENERATION Once the SAS INTRNET process is invoked, it will be running in the Application Server just as a normal SAS job does. The difference is that, once finished, it will deliver the output (html, pdf, doc, etc.) to the user’s browser through the Web Server.

The report in Figure 6 was produced when the “default” service executed the DynamicReport.sas program. The program uses ODS to create HTML output from PROC REPORT, PROC GCHART, and PROC GPLOT proce-dures. The following is part of the SAS code that generates the HTML report.

ods tagsets.hietpl options(t1="&t1" t2="&t2" t3="&t3" t4="&t4" date="&date") body=_webout path=&_tmpcat (url=&_replay);

[PROC REPORT] [PROC GCHART]

ods tagsets.hietpl close;

The BODY option in the ODS statement directs ODS to send the output to “_webout” destination, a predefined reference that sends the output back to the Web browser through the Web Server. The PATH and URL parame-ters allow graphs to be added to the output properly. The predefined tagset hietpl is used, which creates a tagset, a type of template created by PROC TEMPLATE that defines how to generate a markup language output type from SAS output. ODS OPTIONS is used to pass the macro variable value in the SAS program to the tagset.

Figure 6. HIE Data Query System Output (Simulated Data)


13

CONCLUSIONS SAS software plays a most important role in the HIE HL7 data processing system in NYSDOH. When used with a task scheduler, it can automatically access different types of database, integrate the data from multiple data sources, initiate data transmission, and monitor the data processing status. It also supports dynamic data analy-sis and visualization. Overall, it is an excellent choice for automatic data processing systems.

REFERENCES SAS 9.1.3 Documentation URL: http://support.sas.com/documentation/onlinedoc/91pdf/index_913.html SAS Web Tools: Static and Dynamic Solutions Using SAS/INTRNET Software Course Notes, 2001 SAS Institute Inc. SAS Web Tools: Advanced Dynamic Solutions Using SAS/INTRNET Software Course Notes, 2001 SAS Institute Inc.

ACKNOWLEDGMENTS SAS and all other SAS Institute Inc. product or service names are registered trademarks or trademarks of SAS Institute Inc. in the USA and other countries. ® indicates USA registration.

Other brand and product names are registered trademarks or trademarks of their respective companies.

CONTACT INFORMATION Your comments and questions are valued and encouraged. Contact the author at:

Enxu Zhao Bureau of Healthcom Network Systems Management

New York State Department of Health 800 N Pearl St, Albany, NY, 12204 Work Phone: (518)474-9634 Fax: (518)473-1615 Email: [email protected] Web: www.health.state.ny.us

Kathryn J. Schmit Bureau of Healthcom Network Systems Management


Linh H. Le Bureau of Healthcom Network Systems Management



Using SAS to Handle HL7 Messages in A Health Information ... · • Support the data query Web application, run dynamic data queries upon user’s request, ... ” simply displays

Documents