Binding to server COASServer corbaObj: com.ooc.CORBA.StubForObject:com.ooc.CORBA.Delegate@29ce8cResolved 'COASServer' Bind succeeded Getting components Error: can't get QueryAccess component! org.omg.CORBA.NO_RESOURCES: Unable to create client minor code: 0 completed: NoThe COASServer probably is running with Security On and the client is running with Security off (or vice versa). COAS can run securely, but the client must also be running securely if it is to connect properly. Initially, it is best that security be turned off during initial testing of your installation.
All of the servers register to the NamingService in order to "discover" where the server is and make its location transparent. One looks up the name in the NamingService and obtains an Interoperable Object Reference (IOR) which tells the application exactly where the server is and now to contact it. If you have access to the IOR directly, it can be used by itself. The IOR can also be obtained from the Trading service if the server has registered with it.
This answer applies to both PIDS and COAS servers. When a PIDS server starts up it attempts to register to the specified NameService. This registration persists even if the server is shut down. There is no mechanism at present to automatically restart the service if you attempt to connect to it through its registered IOR. The same thing applies if you specify the IOR to connect to and that IOR doesn't correspond to a running service. To clean the nameservice database, run the startnamingservice script which cleans up the database before starting up the service. Similarly, the tradingservice retains references which may no longer be active. Those references can be removed by runing the traderconsole script and selecting withdraw offers. If the trader service type for IdentificationComponent is not registered, you need to follow the service definition in trader.txt and insert it into the trader by selecting Insert/Service Type. The latest (10/15/01) version of the PidServer now automatically creates the Service Type if it doesn't already exist.
All of the configuration for the SIIS (and BSAFER) web application is done through property sheets which are placed in the WEB-INF/classes directory through the building of the Web Archive file according to the JSP/Servlet specification. The relevant files for the SIIS are the siis.properties, pids.properties, coas.properties, and the vaccine.properties files. The siis.properties file specifies primarily the information for the display on the web page. pids.properties provides the parameters to get to the PIDS server, coas.properties the parameters to get to the COAS serverAn example siis.properties file is:
# This file primarily controls the display and input of the interface to the Person Identification Service
#login.users specifies the file name of the users list
login.users=/siis_users
#initialize connections
#serverName is the name of the Pids server in the NameService (overrides the value in pids.properties)
serverName=us/nm/state/doh/Pilot
# SSL switch (be sure your web server supports SSL before turning it on)
siis.SSL=off
# The form.* variables specify the input PIDS variables and their display values
#display lables for the input parameters (columns)
form.labels=Last Name,First Name,Date of Birth,Sex
# The names of the form variables passed on in the post to the web server
form.names=Name:0,Name:1,Birthday,Sex
# types of the form variables for preprocessing in the browser
# ST = string, TS= TimeStamp (TS turns on Javascript checking of the TimeStamp)
form.types=ST,ST,TS,ST
# column width of the form element in characters
form.width=20,10,13,3
# Underlying PID Traits associated with the form names.
form.traits=HL7/PatientName,HL7/DateTimeofBirth,HL7/Sex
# Parent category of the form names so that the elements can be assembled for the HL7 message
form.items=Name,Birthday,Sex
# The display variables control how the output traits are displayed
# PID traits that are to be displayed on the output
display.traits=HL7/PatientName,HL7/DateTimeofBirth,HL7/Sex,HL7/PatientAddress
# The data types of the traits to be displayed to enable postprocessing of the retrieved data
display.types=ST,TS,ST,ST
# confidence is a number from 0-1 controlling the quality of the requested match, 1 being exact match
confidence = 0.5
# uploaddir is the directory to place the uploaded hl7 files in
uploaddir = /tmp
A sample pids.properties file is:
#initialize connections # Name of the PIDS server to connect to serverName us/nm/state/doh/Pilot # value of the NameService to use to find the serverName NameService=corbaloc::localhost:5000/NameService # name of the properties file (less the .properties suffix) to find the security parameters for connecting to the PIDS server # not currently used. orb=/orbA sample coas.properties file is:
# The NameService probably should be the same as in the PIDS configuration but doesn't have to be
NameService corbaloc::localhost:5000/NameService
#serverName is the name of the COAS Server to connect to
serverName COASServer
# orb specifies the orb.properties file to be used for ORB security properties. These contol
# the security of the connection from the web application to the COAS Service.
orb=/orb
The siis_users password file has entries that look like:
dn: cn=User, o=New Mexico, c=US
cn: User
sn: State
email: user@doh.state.nm.us
userPassword: {SHA}Jzb6spHwTmm2LUkMPAk2H1uCRho=
role: submitter
objectClass: top
objectClass: person
which is an LDIF representation for each user. The userPassword is an SHA/MD5
encrypted password. The role is required to be "submitter" if they are going
to be allowed to upload HL7 data
The vaccine display is controlled by the vaccine.properties file:
# SIIS Vaccine Types mapping algorithm #0) Read in list of Vaccine Labels for each CVX Code at startup (may be more than one) #1) Obtain list of all immunization events with CVX Codes for the person from COAS #2) Map CVX codes to the Vaccine Labels. #3) Determine minimal list of Vaccines in report #4) Add each event to the appropriate Vaccine category #5) Order events in each category by date #6) Reorder DT and DTaP combined by date. # This latter can be handled in general by having a Vaccine Category # which could be different than the Vaccine Type and can contain # multiple Vaccine Names. #Mapping of CVX codes to Vaccine Names (may be multiple codes for a single display name) 1=DTaP 2=EIPV/OPV Polio 3=MMR 5=Measles 6=Rubella 7=Mumps 8=HEP B-P 10=EIPV/OPV Polio 15=FLU 16=FLU 17=HIB 20=DTaP 21=Varicella 22=DTaP 24=HEP A-P 3 dose 28=DT 30=HBIG 31=HEP A-P 3 dose 33=PNEUMO 42=HEP B-H 44=HEP B-H 45=HEP B-P 46=HIB 47=HIB 48=HIB 49=HIB 50=HIB,DTaP 51=HEP B-P,PEDVAX (HIB 3 Dose) 83=HEP A-P 2 dose 84=HEP A-P 3 dose 85=HEP A-P 3 dose 88=FLU 89=EIPV/OPV Polio 94=MMR, Varicella 100=PNEUMO 102=DTaP,HIB, HEP B-P #Put the in these ordered groupings 01,02,03,04, etc. # if the CVX code isn't mapped it is not grouped. DT=01 DTaP=01 EIPV/OPV_Polio=02 FLU=03 HBIG=04 HEP=05 HEP_A-P_3_dose=06 HEP_B-H=07 HEP_B-P=08 HIB=09 Measles=10 MMR=11 Mumps=12 PEDVAX_(HIB_3_dose)=13 PNEUMO=14 Rubella=15 Varicella=16 #Facilities (Map the displayed facility name from the "domain" of the Qualified Person Id NM_PHD=INPHORM NM_PHS=Presbyterian NM_IHS=Indian Health PHS_MEDIC=Presbyterian # Maximum range of years to include in the COAS Immunization query yearRange=15
The uploaded HL7 data file is send to the PIDS and COAS servers using
the hl72corba script which runs the gov.lanl.Web.HL72CORBA application.
This application converts all the PIDS data to upper case so that we remove
case sensitivity:
The script is essentially the same in unix/linux with the appropriate
changes in the environment definitions.The HL72CORBA.properties file used
as an argument is as follows:
call ../../config/sethome
set JAVA=%JAVA_HOME%\bin
%JAVA%\java %ORBCLASS% -classpath %XMLPATH%;%TMPATH%;%TM_HOME%\dist\lib\corbamed.jar;%TM_HOME%\dist\lib\OpenEMed.jar;%TM_HOME%\dist\lib\tools.jar;%TM_HOME%\lib\xerces.jar;%TM_HOME%\lib\xalan.jar;%TM_HOME%\dist\lib\clients.jar;%ORBPATH%;. gov.lanl.Web.HL72CORBA -ORBconfig orb.properties -HL72CORBA.properties HL72CORBA.properties
; HL72CORBA configuration file ; Input Source is the path to the hl7 data file InputSource \projects\hl7\cdctest.hl7 ; PIDSXSL is the style sheet to select the hl7 data and format it for PIDS PIDSXSL pids.xsl ; HL7XSL is the style sheet to select the hl7 data and format it for COAS HL7XSL hl7.xsl ; Debug Switch Debug false ; COASServer to connect to COASServer=COASServer ; PIDS is the PIDS Server to connect to PIDS=us/nm/state/doh/PilotThis should process the hl7 file and populate the PIDS servers with the appropriate HL7 data. There is a corresponding class gov.lanl.HL7.HL72DOM in the tools package which functions in essentially the same way but dumps all the data to XML so one can verify how the translation is working.
The password is created by running the application gov.lanl.Utility.IdentitySHA.
.If you run it with no arguments it will print out its usage. A script for
running it is in dist/clients: create_digest.[sh,bat].
It can be used to create the hashed password and also to check a password.
This same class is used to validate the password within the web server.
Normally this function would be handled by an LDAP server, but this provides
functionality similar with a simple users file to read in. This uses the
standard FIPS Secure
Hash Algorithm
The script looks like:
call ..\..\config\sethome.bat set JAVA=%JAVA_HOME%/bin/java %JAVA% -classpath %TM_HOME%\dist\lib\tools.jar;%XMLPATH%;%TMPATH% gov.lanl.Utility.IdentitySHA %*and the output without any arguments looks like:
usage: IdentitySHA [-v] [-s salt] identity ...
or: IdentitySHA [-v] -c digest identity ...
salt is in hexadecimal notation.
digest contains SHA-1 hash and salt, base64 encoded.
The gov.lanl.Web.UserMgr class is used to create a persistent hashtable from a file containing users properties. There is a sample usermgr.properties file in the dist/clients/UserMgr directory (with the usermgr.[sh,bat] script. This file without the .properties suffix must be given to the usermgr script. That file specifies both the file with users specified and the name of the persistent hashtable datatbase that you want to create. This database then needs to be put at the root of the Resin directory so that web applications can read it. You can have multiple databases of users for different applications using this technique. If you use something other than Resin, you will need to determine where the persistent hashtable database can be placed.
There are two places where one must match trait values. One is when one is "looking up" a patient, the other is when a patient is entered into the system and must be correlated to another patient. We will consider the "lookup" case first. The OMG specification does not specifiy how traits are to be matched; it is up to a particular implementation and is not specifiable by the user. The user can request a "quality" of the match (0-1), but the meaning of the "quality" is implementation dependent. The current matching algorithm used in OpenEMed is quite simple and deterministic. It consists of two phases, one which extracts data from the database and the other which refines the data obtained from the database. Each HL7 segment (HL7/PatientName, HL7/Sex, HL7/PatientAddress, HL7/DateTimeofBirth, ...) is a separate field to be used in a query and separately stored in the server database. Each field of the segment is exactly matched (usually case sensitive) to the beginning characters of that field. All candidates traits that have a full set of matching fields is extracted from the database. If any field doesn't match the request, that trait is not returned. The patient ids which have those candidate traits are then extracted with all of their traits. This will create a larger id list than will be returned to the user. The list of traits for the candidate id is examined and a weight for each input trait is created. The scoring is such that any exact subfield match (on the beginning characters) yields a 1.0. If not, it returns 0.0. The total score is added up and divided by the number of fields. So the highest score is 1.0 and lowest is 0.0. If one has two traits to match with no subfields, and only one matches e.g., the score will be 0.5. Some traits are filtered out from the database query because they would return too many "false positive" candidates. HL7/Sex is one because it would select 1/2 of the database. If HL7/Sex is provided on the input, however, it is used in the subsequent scoring. Only those candidates with a score at or above the requested input "confidence" are returned. Although this is not a true "fuzzy" match it has some of the properties, since one doesn't have to have a match against all of the input traits. With this algorithm, it is best to not put too much data in the request, because if it is wrong, it may result in no match. For example, if you are not sure about the patient's middle initial, it would be best to leave it out. Putting in an incorrect middle initial might result in no match (but could still be a match if enough other parameters match).
For the correlation process, same procedure is used, but we typically require a confidence of 1.0, so that all fields must match exactly. This will result in not correlating in many cases, but since this is entirely machine automated, we do not want to have any false positives. Obviously a better algorithm is desirable, but we think this is a good starting point.
The web clients are delivered as a Web application in a web archive file
(.war) that should run with any JSP2.2+ compliant Web server. It is a client
to a separate CORBA servers that runs the OMG's PIDS and/or COAS service
to store and retrieve the data. This enables very flexible deployment by
separating the persistent data store from the web server and separate from
the presentation layer. If the COAS service is already running, the deployment
is quite simple. The The These are configurable through a number of property files in the WEB-INF/classes
directory of each web client that are read in as ResourceBundles. These
property files are in the config
subdirectory of each webapp in src/clients/webapps.
IMPORTANT: If upgrading to a new version of the application, save
all of your modified properties files as they will be overwritten during
the install. You will need to edit your changes into these new files, but
be sure to check for any new variables.
To configure for a given location: first check out <app>.properties
We describe here the variables that need to be set for B-SAFER application
There are 6 alert web pages that are defaulted to the local values but
the commented out values are for the New Mexico Dept of Health references.
The default values refer to localhost:8080 for the local web server. Change
this according to the name and port of the local web server if running without
the NM links.
If this is used outside of New Mexico, the map server will also have to
be configured. We don't provide that documentation here.
The users file is the LDIF formatted file with the allowed users on the
system. The coas.properties file has the NameService and COAS server name to be
connected to
The "localhost" reference should be changed to the machine's name that
has the Nameservice and the serverName should be the COAS service in that
NameService
For example, if the Nameservice is on esmerelda.acl.lanl.gov and the COAS
service is also defined in that NameService as BSAFERServer the coas.properties
file should read:
The login.users specifies the file of users authorized to login
facility is the Name of the facility where the data is being
collected
zipcodes specifies a file containing the zipcodes that are
in the drop down list (see zipcodes for format)
domain is the domain where the data is being collected (format:
DNS:lanl.gov)
code specifies the prefix on the Codes to be sent to the COAS
server
SSL=on turns on SSL for the application (only works if SSL
is supported by the underlying JSP engine)
map is the properties file that defines the properties for
generating the ARCIMS maps
alert.[1..n] is a list of XPATH queries to determine if a
possible reportable disease has occurred. There can be an arbitrary number
of these alerts. They are used to send an email alert to the smtp addressee
below.
mail.smtp.host is the name of a local smtp server that the
user can connect to to send mail
mail.smtp.to is the address to send alerts to (should be bsafe@doh.state.nm.us)
RESIN issues. We are using Apache Jakart's implementation of XSL. When running
Resin (http://www.caucho.com), you may need to change the default DocumentBuilderFactory
by adding to the httpd command line:
-J-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
Also, the parameter -J-Dlog4j.configuration=log4j.properties
may be needed for applications to read in the proper log4j setup.
NameService corbaloc::esmerelda.acl.lanl.gov:5000/NameService
serverName BSAFERServerreport.properties files has the list of Syndromes that
reports are created for and the variable Sleep is set to the number of milliseconds
between updates