PRS

In PEI's case, WHIC provider registry has not been implemented and there are no current plans to do so. Instead, the DIS - through the CeRx messages - has enough provider information to indicate who performed a particular action. The provider information extends to basically: identifiers, provider name and the provider role type. If the province wants to for some reason distinguish between prescriptions written by doctors and interns, the provider role type is the only thing they have to do so.

In BC, the colleges use the File transfer utility (FTU) to upload HL7 batch files.

The responses are sent back as described below.
Yes you have the understanding of HL7 FTU, when they install the app on
their server or PC they stipulate a file upload and download directory
which is written into the config file (prs-filetransfer.xml), they also
accept a bunch of default values that are written to this file as well.

The config file contains (what this stipulates is that any response file
(Pattern RESP) with a status of READY_ONLY can be retrieved):

SERVICE>
MULTIPLE_DOWNLOAD_FILE_STATUS
READY_ONLY


MULTIPLE_DOWNLOAD_FILE_PATH
C:\FTU_DOWNLOADS


MULTIPLE_DOWNLOAD_FILENAME_PATTERN
RESP


Then they can use Microsoft scheduler to get and send files. Basically
they schedule the following command:

ft mdown (multiple download)

this is detected by the bat file which includes (the xxxx is a fake
password):

REM usage: mdown eg. mdown
:mdownload
java %mem_opt% %cp_opt% com.filetransfer.FileTransfer -md prs-cdsbc.1ps
xxxx -e C:\Hl7xfer\config\prs-filetransfer.xml
goto end

So this gets their responses to files they uploaded the previous day,
and downloads them into their download directory.
(So you are correct in that they do have to issue a "Get File" command
but they do not have to know the name of the file)

Then they have scheduler execute the following command:

ft mup (multiple upload)

this is detected by the bat file which includes (the xxxx is a fake
password):

REM usage: mup eg. mup
:mupload
java %mem_opt% %cp_opt% com.filetransfer.FileTransfer -mu prs-cdsbc.1ps
xxxx -e C:\Hl7xfer\config\prs-filetransfer.xml
goto end


This will cause all files sitting in the upload directory to be set to
PRS to the following (from the config file for Dev, note: they have to
have a correct certificate), and if successful the files are removed
from the upload directory:


FILE_TRANSFER_URL

https://prsd2.moh.hnet.bc.ca/hl7xfer.jsp>


And the next day the whole process is repeated.

Note: Therefore the very first time they do this they will have no files
to download, but after that they will always pick up the responses from
the previous days upload.

Note: They are able to quickly determine that something went wrong if
the
files are still sitting in the upload directory. They are also able to
then
send them, again, although I think all the sources keep/have backups
anyway.

Note: Debbie Boylan can view the RESP files using her RegAdmin ID via
the web interface, and this will not change the status of the file.
Viewing with most other ID's (and once the file is downloaded) will
cause the status of the response file to change.

.
If a message is received by the PRS, it performs the following checks to ensure that the message is authorized to process:
1. SENDING_ORGANISATION_CHID - This must be the same as the Org ID of the Registry User uploading the file.
2. SENDING_JURISDICTION_CODE - This must be the same as the Home Registry Jurisdiction.
If the message fails these checks, the bean will send an acknowledgement indicating that they are not authorized. However, if the message is missing required fields or has an invalid message format, an exception is thrown while the bean is attempting to return the acknowledgement. Thus, no acknowlegement is generated and the file is never processed due to the exception.

Andrew Cripps and Brad Head spoke at eHealth 2007:
http://www.e-healthconference.com/_ehealth2007web/pdf_presentations/wed_use_of_ehr_cripps.pdf

The AS_OF_DATE is used to search through data that was active as of (at the time of) the specified date. This means that the record has an EFFECTIVE_END_DATE > AS_OF_DATE. This does not mean that the EFFECTIVE_START_DATE is not > the AS_OF_DATE. The AS_OF_DATE is not used to match on records that were effective at the time of the specified date.

Disabling explicit garbage collection is a WebSphere JVM setting. Depending on which version of WebSphere you are using this setting might be in a different place. Here is where we made the change.

In the WebSphere administrative console under Servers > Application servers > {the app server to change} > Java and Process Management > Process Definition > Java Virtual Machine. In the field called “Generic JVM arguments” set the following value “-Xdisableexplicitgc”. When researching this we also noticed that this value may be different depending on the operating system (we used Windows). On a Solaris system the value was “-XX:+DisableExplicitGC”. AIX, being a UNIX based OS might use the same settings as Solaris.

Labels: JVM, PRS

Be careful when hosting RMI for client and server on the same machine. If your config files are not correct you could end up using the same location for client permissions and server permissions in RMI, so when client permissions loaded, they trash server permissions (and vice versa)

The behaviour of the client (or server) will gave it away: when you refresh server rmi, the client will stop working properly.

- Tip from Pat W.

Effective dates are from midnight. So that means that Jan 17th 00:00 is start and to get a 24 hour period we need an end date of Jan 18th 00:00.

If you put Jan 17th (00:00) and Jan 17th (00:00)then you have validity of zero time.

It was nice to speak to you earlier, as you requested, here is the
processing time for PRS:
- a HL7 version 3 file uploaded at 2:29 am, took 15 seconds to run for
35 transactions.

Unfortunately, all the files for the past week have been small, I
imagine due to the time of year, there is low activity. The week of June
4 - 8th, the CPSBC averaged 124 transactions a day.

During the month of January 2007, the RN averaged 365 transactions per
day for the first week, 569 transactions per day the 2nd, 549
transactions per day for the 3rd and 629 transactions per day for the
4th week of January. The volume is considerably higher at different
times of the year, depending on the activity at the Colleges. During the
month of February, the College of Physicians and Surgeons averaged 336
transactions per day.

AssignedEntity conveys that an entity (person) is acting on behalf of an organization. HealthcareProvider conveys that a person is authorized to provide health care services by some authorizing agency. There is nothing in those two roles that explicitly or implicitly states that an AssignedEntity is also a HealthcareProvider. However, the Personnel Management information model allows you to assert that a particular AssignedEntity is also a HealthcareProvider by including a relatedTo role link association between the two roles.



You can see this in the Personnel Management DMIM model at http://www.hl7.org/v3ballot2007may/html/domains/uvpm/uvpm.htm#dmims-PRPM_DO000000UV-ic

In order to get the PRS application deployed and running on WebSphere 6.1, fixpack 7 needs to be installed to bring WebSphere up to 6.1.0.7.

create index NM_UPPER_SURNAME_I on GRS_PERSON_NAMES

(upper(PRSN_SURNAME_TXT))



create index NM_UPPER_FIRSTNAME_I on GRS_PERSON_NAMES

(upper(PRSN_FIRST_GIVEN_NAME_TXT))



create index PID_UPPER_PROVIDERID_I on GRS_IDENTIFIERS

(upper(PROVIDER_CHID))

A question about the acknowledgement codes in the transport wrapper came up. Ack code deals with transmission-level errors and not message processing errors.

So if we are able to parse and process the message, the acknowledgement code is always 'AA' even if the interaction sent back a refusal, i.e. there were issues. AE/AR would only be returned if there were errors being returned in the transport wrapper.

Given that interpretation, the question arose on when an AR would ever be returned. I couldn't think of a scenario where I'd be able to return this code. When would I ever not being to process a message because of content or format? That's what the description for AR says.

>>You are correct in your understanding of the use of ‘AA’. With respect to the use of ‘AE’ and ‘AR’, ‘AE’ is used when there's a problem with the message (e.g. bad XML); ‘AR’ is used when there's a problem with the receiving system (e.g. database down).

From the CeRx forum.

Scenario 1

The fact that only one CPN is being distributed shouldn’t be a problem. In this scenario, the only change that takes place is the CPN of the provider being merged, is changed. This is apparent from an ENTIRE PRIOR distribution. This also indicates which provider the link is made to, i.e. the new CPN. This is just a link between two providers and new link information is available.



Scenario 2

This merge scenario is basically saying that there is a duplicate provider and that the provider should be deactivated. The information that is sent out is that a provider has been deactivated. As no real merge took place this information is really what is needed to keep downstream systems in sync.



Scenario 3

In this scenario, information for both, the survivor and non-survivor, is distributed.

We do not have legislation in SK for Provider data. In 2004, SK modeled our
Data Sharing Agreements from the original BC approach. Today, we are
preparing a Privacy Impact Assessment and hope to get agreement from all
sources for a "Shared Accountability Model" for data quality and governance.
Second, each consumer would be required to agree to the "Service Policy" -
defines the purpose, use and disclosure of Provider Data. Any use outside
of the Service Policy would require the consumer going back to the source
for permission

• Bufferpool with 8KB page size
• Bufferpool with 16KB page size
• Regular tablespace with 8KB page size (uses 8KB bufferpool)
• Regular tablespace with 16KB page size (uses 16KB bufferpool)
• Temporary tablespace with 8KB page size (uses 8KB bufferpool)
• Temporary tablespace with 16KB page size (uses 16KB bufferpool)

Will add a table here.

1.1.1 HN202605 - Support true merge/unmerge of duplicate providers
This change request is part of the employed providers enhancement.
If duplicate providers are inadvertently created, they can be merged. This enhancement provides a way to merge one provider with another. In release 2.05, duplicate providers were linked, but in release 3, the design is to provide a “deep” merge of one provider with another.
1.1.1.1 Requirement(s)
This enhancement is related to the following Release 3 enhancements:
• HN-202670 Employed Provider
• HN-202670 Enhanced Searching and Matching
For Employed providers, there will be many occasions where the same individual (person) holds several jobs in more than one agency. Furthermore, it is likely that many organizations will be Primary Sources for the same Provider Type.
It is likely that uploads or XML messages from multiple sources will contain data about the same person, in a single role or in different roles.

PRS’s ability to avoid creating duplicates during the creation of providers was enhanced in Release 4. Despite enhanced searching and matching functionality, it is expected that duplicates will be created and that the number of duplicates may increase. PRS’s ability to resolve duplicates was therefore enhanced.

Duplicate resolution includes the ability to reference (or associate) each unique identifier with any other unique identifier (CPN). This is to accommodate duplicate record errors since unique identifiers cannot be deleted. Therefore a user should be able to look at any unique identifier record and determine all instances where this identifier is referenced to or associated with any other unique identifier. Also if two records have been related in error there needs to be the ability to un-relate or disassociate the two records.

The unique identifier should be sharable, and available for access and use by all users.
Implementation of these requirements must also support the following merge rules:
• Duplicates are never deleted but are ceased and the ceased record points to the non-ceased record (forward referencing)
• Resolution of Duplicate Providers must be done manually; that is, a person must make the decision as to which record to retire/cease—this cannot be done automatically by PRS
• Each merge decision must be reversible
1.1.1.2 Analysis
In Release 3, PRS supported only linking providers with the same CPN. The Release 3 link process was completed through the Resolve Duplicate Search Results Screen function. Selecting ‘duplicate’ Provider records and pressing the “Merge” button results in PRS changing the CPN for the selected duplicate Providers to that of the ‘target’ Provider. The CPNs of the duplicate Providers are in effect ‘ceased’. The ceased CPNs are no longer accessible—that is, no history is kept on ceased CPNs that is viewable by Registry Users. No history on CPNs means that it is difficult to track if two Providers have been linked in error. Furthermore, there is no ‘unlink’ functionality in PRS if two Providers have been linked in error.
The crux of the problem in linking Providers is that in the real world, at any one time, a Provider can be linked to only one party, but over time, the provider might be related to several. Although the PRS database tracks history, in Release 3 it only allowed for a provider to be linked to one party, so it was unable to maintain details of “CPN History”.

Following are scenarios that illustrate situations that may occur within PRS with the introduction of Employed Providers functionality (Release 4). Merge and Unmerge functionality are addressed within separate subsections.
1.1.1.2.1 Merge
The following scenario illustrates the Release 3PRS duplicates resolution functionality:

Scenario 1: Two sources create two different Providers who are the same Party.



Using the Resolve Duplicate Search Results Screen, the Registry User that is resolving the duplicates needs to cease (Party) CPN 0335 and link to (Party) CPN 0224.



The desired result is that there are now two Providers, Jane MD and Jane Pharmacist under a single CPN 0224.BC.PRS. Although this link functionality is supported in PRS Release 3, what is not supported is forward referencing. That is, if a Registry User subsequently searches for the second Provider (CPN 0335.BC.PRS), Release 3PRS will not point to the first Provider (CPN 0224.BC.PRS).

The following diagram illustrates the result of Scenario 1 with ‘forward referencing’: pointing the ceased Party to the target Party.





Following are two additional situations that may result in Duplicate Providers but unlike Scenario 1, cannot be resolved in Release 3 PRS. Both situations are analysed through scenarios.

• A single source records the same Provider twice on PRS with minor changes to the data elements (e.g. name).
• Two sources create two versions of the same Provider, each with their own data.

Scenario 2: A source records same Provider twice on PRS with minor changes to the data elements (e.g. name).


The Registry User that is resolving the duplicates needs to cease the second Provider entirely, as it was added in error.


The desired result is that the second Provider is ceased. However, if a Registry User subsequently searches for the second Provider (CPN 0335.BC.PRS), PRS will point to the first Provider (CPN 0224.BC.PRS). Pointing to a Provider after ceasing another when they are logically associated with each other (also known as forward referencing) is not supported in Release 3 PRS.

Scenario 3: Two sources create two versions of the same Provider, each with their own data.



Using the Resolve Duplicate Search Results Screen, the Registry User that is resolving the duplicates needs to retain HA2’s data objects (Name, Status, Provider ID, and Work Location) but point to the original Party/Provider. Note that HA2 does not wish to change HA1’s data, but to add their own set of the Provider’s data.



The desired result is that HA2’s data objects are merged with HA1’s data objects under the same Party/Provider. Both ceased Party and Provider point to the target Party and Provider.
1.1.1.2.2 Unmerge
The Release 3 link functionality has been enhanced and expanded in Release 4 to include merge functionality to support the business scenarios above. As stated earlier, there is no ‘unlink’ functionality in Release 3 PRS if two Providers have been linked in error. The scenario below illustrates a business situation that could occur for which unmerge functionality is required.

Scenario 4: Provider data submitted by two different sources was merged in error.

This scenario builds on Scenario 3. An error was made in merging HA2’s data with HA1’s data: Party 0224.BC.PRS and 0335.BC.PRS are, in fact, two different people.


The registry user needs to be able to restore PRS’ data to the state before the merge.



The desired result is that HA2’s Party, Provider and data objects are unmerged from HA1’s. There are now two separate Parties: Jane Brown, Lab Tech submitted by HA1 and Jayne Brown, Lab Tech submitted by HA2 are two different people.
1.1.1.3 Solution
To meet the above requirements and to support the above business scenarios we propose the following enhancements to PRS:
• Modify the database and application design, to support multiple (historical) linkages between a Provider and a CPN
• Modify Resolve Duplicates functionality to implement the 3 merge scenarios outlined above.
• Modify Provider Query functionality to “follow” forward references.
• Modify Provider Maintenance functionality to allow maintenance operations to allow merge and undo-merge operations.
Each enhancement is described in more detail below.
1.1.1.3.1 Support multiple (historical) linkages between a Provider and a CPN
Modify the database design to support multiple linkages between a Provider and a CPN as follows.
In the proposed model, CPNs and IPCs are both regarded as Registry Identifiers. They are subject to permission control, but they cannot be placed in Data Sets.
The database enhancement will be reflected in Provider Query and Provider Maintenance XML schemas, and in the Provider Details/Maintenance Web screen. The following screen shows current CPN and IPC, and historical CPN and IPC, as would be apparent after a scenario 3 merge.

Figure 46 Provider Data and Registry User Identifiers after a Merge
This Provider contains some data that was merged-in from CPN 335. Forward referencing works because a query on CPN 335 will match this provider. Any search on data merged in from the original CPN 335 will also match this provider.
CPN and IPC will be protected by data permission control, and historical display controls (Show Audit, Show History) just like any other object. However, they may only exist in a single “SYSTEM” data set. (The name of this Data Set is never shown in the outline control above).
1.1.1.3.2 Modify Resolve Duplicates Functionality
The Release 3 Resolve Duplicates screen functionality and XML schema will support the functionality required:

Figure 47 Resolve Duplicates Screen
Modification was required on the server side (MaintainPotentialDuplicatesBean) to treat each identified pair as follows. Suppose in the following example that Provider A is to be kept, and Provider B is to be merged/linked.
If Providers A and B have different role types (Scenario 1 merge), perform a LINK as follows:
Cease B’s current CPN
Create a new CPN for B, equal to A’s current CPN
If Candidate and Trigger have the same role type, and were created by the same source (Scenario 2 merge), cease Provider B as follows:
Cease B’s current CPN and IPC
Create new, CEASED CPN and IPC for A, equal to B’s old CPN and IPC
If Candidate and Trigger have the same role type, but were created by different sources (Scenario 3 merge), perform a true merge as follows:
Cease B’s current CPN and IPC
Create new, CEASED CPN and IPC for A, equal to B’s old CPN and IPC
Attempt to copy each of B’s data objects to A. If any business key collisions occur, reject the transaction, listing all collisions in the error response (the Registry Administrator will need to resolve these collisions). This could be achieved by simply creating a MaintainProvider transaction out of B’s data.
1.1.1.3.3 Merging a Merged Provider
There might be a case where a merged provider must be merged again with another provider. Forward referencing will still work in this case. After a merge of two providers, the merged provider (say Doc 2) has effectively disappeared from view because it no longer has a current registry ID. The surviving provider (say Doc 1) has a copy of the merged provider’s CPN as a ceased entry. Now if Doc 1 is to be merged with Doc 3, and Doc 3 is the survivor, then Doc 1 effectively disappears because it will not have a currently active registry ID after the merge. Doc 3 will have a currently active registry ID, and a copy of Doc 1’s registry ID that has been ceased.
1.1.1.3.4 Modifications to ProviderQuery functionality
Provider Queries must be modified in two ways:
• Providers without an active CPN must not normally be returned (regardless of whatever other data are active), except.
• CPN or IPC searches must match INACTIVE CPNs or IPCs. This will allow Provider A (in each merge scenario above) to be returned when Provider B’s CPN or IPC was used as a search criterion.
The first point is important because it allows the Registry Administrator to find providers with no active CPN. In order to assist the Registry Administrator, this special search will be available from the provider menu, beneath “Dupl.” (for “Duplicates”).

Figure 48 Screen Mock-up of Unmerge button
When the Registry Administrator click on the unmerge button, a search screen appears that has a single search query parameter field for the CPN. The unmerge button is controlled by functional permissions and will be visible only to users with that functional permission.
A separate search screen solely for Registry Administrators who need to unmerge providers is an aid to establishing a mental mode of operation that will assist in accurate and careful consideration of unmerge operations.

Figure 49 Special Provider Search screen mock-up
The result of the search will be the provider search results screen. The Registry Administrator should see the providers to be unmerged in the results if the CPN was specified correctly as a search parameter.
The Special Provider Search actually calls the normal provider query method, but sets a parameter that tells the method to disable all other parameters in the search, make the confidence level 100%, and INCLUDE INACTIVE PROVIDERS (ie those without active registry identifiers).
To unmerge, the Registry Administrator identifies the two providers to unmerge, one of which is to be reactivated. The Registry Administrator unceases (recreates) the registry ID from the merged provider. This effectively makes the merged provider visible again. The registry administrator must use the provider details report to compare the two providers. If changes have occurred while the two providers were merged, those changes must be applied to the unmerged provider again. Similarly, any information that was copied to the retained provider from the merged provider must be ceased.
The second point is important because queries can still be conducted successfully by users who have retained old identifiers. Since ceased CPNs and IPCs are searched, and the CPN and IPC of a merged provider became ceased items in the retained provider, the retained provider will be found when an old identifier is used.
The rule that only providers with active CPNs / IPCs are returned by the provider search is enhanced slightly to support unmerged providers. If the same CPN or IPC is found to be ceased in one provider, and active in another, then ONLY the active provider is shown. This prevents two providers being returned after an unmerge, as would happen if the search implemented the search rule without modification.
In summary, the rules for searching are as follows:
1. Exclude from the result set any provider that does not have an active CPN.
If the same CPN/IPC is ceased in one provider and active in another of the same role type, return the active one. Thus ceased CPNs and IPCs do not match if there is an active one for a provider of the same role type.
2. Create a special provider search that allows registry administrators (or those with the correct functional permissions) to search by CPN only for providers with an active or inactive matching CPN.
3. If the CPN is passed as a parameter to the provider search, then all other search parameters are disabled, and the confidence level is always 100%.
1.1.1.3.5 Modifications to Provider Maintenance to support Merge and Unmerge
Provider Maintenance functions were modified in Release 4 to support Merge and Unmerge as follows:
• A Registry Administrator must be able to violate the following business rules in order to allow them to resolve business key collisions prior to performing a merge:
o Cease last Identifier
o Cease Name of default type
o Cease Status Record
o Cease Demographic Record
• There will be no “unmerge” functionality. Unmerging will be accomplished by manual reactivation and ceasing of IPCs and CPNs, which will only be available to Registry Administrators.
The requirement to unmerge is supported by providing a search for Registry Administrators that allows them to find providers that have no active CPN. This is needed so that the registry administrator can locate providers to unmerge.
1.1.1.4 Software changes
The software changes that must be made are:
• Modify provider_details_tree.jsp to improve clarity of presentation of material.
• Modify MaintainPotentialDuplicates to implement the three merge scenarios.
• The database schema must be modified to support a provider having many CPNs and IPCs.
• Provider query functionality must be modified to follow forward references (from a duplicate provider to the new retained provider).
• Modify MaintainPotentialDuplicates method maintainDuplicateEntries to implement merge and unmerge operations.
• Modify MaintainProviderBean to allow suspension of regular business rules for Registry Administrators attempting to perform a merge.
1.1.1.5 Business and Technical Impacts
There are no business or technical impacts to existing PRS functions or data.

MERGES
A true merge was requested. This is a case where the data from the provider being merged is copied to the provider being merged to. However, there was a collision of data, specifically the identifier, as the failure message indicates and thus the data from one of the providers must be ceased before proceeding with the merge. Since the transaction failed and the response message does not have a placeholder to return the data of the potential duplicate set, there is no data displayed and the user must requery to retrieve the data. This can be done by clicking on the LIST button on the same screen, or by going to the potential duplicate search page

http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rzala/rzalaco.htm

This rule has at least one exception to it which has to do with names. In the case of names, the user must have permission on at least one name type in order to perform the search. This was put in place as the search parameter for org name and surname is the same from the web client

The opportunistic search trap kicks in if you try to search on a particular element of an object without having permission on all the elements in the object. To avoid the OST, grant permissions on all the elements of an object for a given qualifier, or specify the qualifier for which you have permissions in the search.

If you have permissions on address line 1, you're going to get caught with a wide open search on addresses. Similarly if you have permissions on all elements of address for "Business Contact" you're going to get caught unless you specify "BC" in your search.

Find duplicate provider queries in the Jurisdictional Registry Administrator's Guide.doc

If Oracle suddenlytakes loads ofmemory and CPU, then it might be that you need to go to the oracle cmd line or enterprise manager and "analyse statistics"

For some reason we encountered this on an ORacle 10g installation and it fixed the problem.

If Oracle suddenlytakes loads ofmemory and CPU, then it might be that you need to go to the oracle cmd line or enterprise manager and "analyse statistics"

For some reason we encountered this on an ORacle 10g installation and it fixed the problem.

The statement of which fields accept wildcards is in the "PRS Interface Design" document. It shows pictures of all the screens and indicates whether wildcards can be used or not.
Note that with HL7 SFU, the percent cannot be used, asterisk must be used.

There is an interprovincial Provider Details Report interaction available.
This can also be requested through HL7 (release 4 flavour).

The final drop of PRS release 4.1 went over to UAT on Friday - testing begins on Monday.

All transactions are treated as MaintainProvider transactions. The PRS does not know whether the provider is to be created or updated until it finds an existing provider based on the incoming data. If a provider already exists, the PRS continues to update the existing provider with the data in the message.Before actually updating the data, the PRS performs change detection. If the PRS determines that there is no change in the data it does nothing and returns a SUCCESS message. If the PRS does detect change, but no End Reason Code is supplied (as in the case of a add provider message), the PRS will return a failure indicating that no End Reason Code was supplied. If the user wanted to explicitly create a duplicate provider with exactly the same data, the Assertion Flag should be checked. This indicates to the PRS that, if the provider does exist, do not update the existing provider's data, but add a new provider. The PRS will create new provider and create a potential duplicate entry.

 



	Also new…   DataDirect XQuery, Release 2.0 A Powerful Java component for integrating XML and Relational Data DataDirect Connect for ODBC, Release 5.2 DataDirect Connect for ADO.NET, Release 3.0 Any questions? Contact us. Architect Tutorials 2006 June 20 - Santa Clara June 21 - San Francisco June 27 - New York June 28 - Toronto Sponsored by the International Association of Software Architects and DataDirect Technologies Learn more and register today   DataDirect Expands on its Technical Leadership with the Latest JDBC Drivers There’s a reason why more Java developers use DataDirect for their JDBC data connectivity: it’s proven. Proven to be the most scalable, best performing, and most reliable JDBC driver on the market. That’s also why Sun, Oracle, and IBM use DataDirect drivers in their application servers. With Release 3.6, DataDirect expands on that leadership with new functionality and the latest database version support. Release 3.6 adds support for Operating System (OS) authentication to additional databases, application client environments, and KDCs (Kerberos Key Distribution Center), and adds new database support for Oracle 10g R2, SQL Server 2005, and Sybase 15. Release 3.6 highlights: OS Authentication (aka Single Sign-On/Kerberos)Expanded OS authentication support for DB2, Microsoft SQL Server, and Sybase allows you to create a Single Sign-On environment that bolsters security, eliminates the need for users to log in separately for each application, and reduces the costs associated with managing user accounts. New Database Support for Oracle 10g R2, Microsoft SQL Server 2005, and Sybase 15 DataDirect always offers you the latest database support so you can leverage the database version and features best suited to your environment. Try DataDirect Connect for JDBC 3.6 now. To learn more about what’s in Release 3.6, see the Release Highlights. Sincerely, Mark Troester Senior Manager, Product Marketing DataDirect Technologies P.S. Be sure to visit the Developer Center for code examples and the latest articles on performance and using DataDirect JDBC drivers with JBoss, WebLogic, Tomcat, and other technologies.
	Copyright © 2006 DataDirect Technologies. All Rights Reserved.

You are receiving this email because you have done business with DataDirect.
If you prefer not to receive email communications from DataDirect, you may manage your subscriptions here.

DataDirect Technologies, 14 Oak Park Drive, Bedford, MA 01730

----Notice Regarding Confidentiality----
This email, including any and all attachments, (this “Email”) is intended only for the party to whom it is addressed and may contain information that is confidential or privileged. Sierra Systems Group Inc. and its affiliates accept no responsibility for any loss or damage suffered by any person resulting from any unauthorized use of or reliance upon this Email. If you are not the intended recipient, you are hereby notified that any dissemination, copying or other use of this Email is prohibited. Please notify us of the error in communication by return email and destroy all copies of this Email. Thank you.

-----Original Message-----
From: owner-xml@lists.hl7.org [mailto:owner-xml@lists.hl7.org] On Behalf Of
Patrick McCormick
Sent: Wednesday, June 07, 2006 3:02 PM
To: Smithies Rik
Cc: charlie@ramseysystems.co.uk; xml@lists.hl7.org
Subject: Re: Canonicalizer ?

Hi,

libxml's xmllint (http://www.libxml.org/) can handle this with the "--c14n"
option. Here's a test I threw together that shows it generating the same
output from two similar but not identical XML files:

[~]$ cat bad.xml
<some><tag quux="baz" foo="bar"/></some> [~]$ cat bad2.xml <some><tag
foo="bar" quux="baz"></tag></some> [~]$ xmllint --c14n bad.xml <some><tag
foo="bar" quux="baz"></tag></some> [~]$ xmllint --c14n bad2.xml <some><tag
foo="bar" quux="baz"></tag></some>

Libxml implements the W3C's Canonical XML recommendation.

I have it as part of Cygwin (http://www.cygwin.com/) but you can download
native win32 libraries here:

http://www.zlatkovic.com/pub/libxml/

Get "libxml2-...zip" and "iconv-...zip". Unpack libxml2, then copy the
iconv.dll file from the iconv zip to the "bin" directory where xmllint.exe
is. That's all you need to run xmllint.

I should mention how great Cygwin is -- it's big, but you end up with nearly
every open source program you could ever need sitting on your hard drive,
ready to run from a shell window.

best,
patrick

--
Patrick McCormick
Columbia University College of Physicians & Surgeons Class of 2008
pjm2109@columbia.edu

Smithies Rik wrote:
> Thanks Charlie, that's the only one I could find and the download page
> isn't there any more.
> Rik
>
>> -----Original Message-----
>> From: Charlie McCay [mailto:Charlie@ramseysystems.co.uk]
>> Sent: 07 June 2006 12:25
>> To: Smithies Rik; xml@lists.hl7.org
>> Subject: RE: Canonicalizer ?
>>
>> Rik
>> I have used www.elcel.com/products/xmltools/xmlcanon.html in
>> the past -- but am having web access problems that the moment
>> so cannot confirm that it is still there and working All the
>> best Charlie
>>
>>
>> Charlie McCay, charlie@RamseySystems.co.uk Ramsey Systems
>> Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES
>>
>> tel 01743 232278 / 07808 570172 skype: charliemccay
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: owner-xml@lists.hl7.org
>>> [mailto:owner-xml@lists.hl7.org] On Behalf Of Smithies Rik
>>> Sent: 07 June 2006 12:19
>>> To: xml@lists.hl7.org
>>> Subject: Canonicalizer ?
>>>
>>> Does anyone know of a free XML canonicalizer that can be
>> used from a
>>> command line (windows) ?
>>> I know some APIs support it, but I'm looking for something canned.
>>> thanks,
>>> Rik
>>>
>>> This e-mail is confidential and privileged. If you are not the
>>> intended recipient please accept our apologies; please do not
>>> disclose, copy or distribute information in this e-mail or take any
>>> action in reliance on its contents: to do so is strictly prohibited
>>> and may be unlawful. Please inform us that this message has gone
>>> astray before deleting it. Thank you for your co-operation.
>>>
>>>
>>>
>>> ************************************************
>>> You are currently subscribed to xml@lists.hl7.org as
>>> charlie@ramseysystems.co.uk To unsubscribe from this list,
>>> send a blank email to leave-xml-164023L@lists.hl7.org To
>>> access the Archives of this list, go to:
>>> http://lists.hl7.org/read/?forum=xml
>>> To access your List Server profile and subscriptions, go to:
>>> http://%%site.domainname%%/read/login
>>>
>>>
>
> ************************************************
> You are currently subscribed to xml@lists.hl7.org as pjm2109@columbia.edu
> To unsubscribe from this list, send a blank email to
leave-xml-164023L@lists.hl7.org
> To access the Archives of this list, go to:
http://lists.hl7.org/read/?forum=xml
> To access your List Server profile and subscriptions, go to:
http://%%site.domainname%%/read/login
>

************************************************
You are currently subscribed to xml@lists.hl7.org as hl7@cripps.net
To unsubscribe from this list, send a blank email to
leave-xml-164023L@lists.hl7.org
To access the Archives of this list, go to:
http://lists.hl7.org/read/?forum=xml
To access your List Server profile and subscriptions, go to:
http://lists.hl7.org/read/login

If PRS does not return the expected format when requested as "HTM" or other with "FAILWARN" etc, check that the right XSL is installed.

PRS does generate a CPN and an IPC when a provider
is created. Reloads count as provider creates.

However, the CPN and the IPC can be updated using the same reload batch file with a few modifications (e.g. adding the CPN and IPC with an End Reason Code of
CORR for each).
I.E. You can UPDATE the CPN and IPC, but not Add.

Location of files on Ministry Server
\\seal\Apps\Prod\Test_Dir\PRS\pln-atchmnt

We have fixed the "class not found" problem and was able to start the
server RMI on AIX on Friday.

In case you are interested in the cause of the problem, here is a brief
summary.

Turns out the problem was caused by the settings in the
prs-rmiservices.xml file where the three services were defined. The
service lookup attribute seems to require an explicit RMI URL prefix in
order to work in AIX.

[Before]

<SERVICE>
<SERVICE_NAME>CONFIGURATION</SERVICE_NAME>
<SERVICE_LOOKUP>dev_4/grs/config</SERVICE_LOOKUP>
</SERVICE>

[After]

<SERVICE>
<SERVICE_NAME>CONFIGURATION</SERVICE_NAME>

<SERVICE_LOOKUP>rmi://127.0.0.1/dev_4/grs/config</SERVICE_LOOKUP>
</SERVICE>

Cheers!

David Chen

The DDL needed changing when installing PRS in Quebec because some column definitions included defaults for to_date(`30-dec-9999`,DD-MON-YYYY)
but in fact the month DEC is not valid for the French locale.

The DDL needs to be modified to make the defaults of the form: to_date(30-12-9999,DD-MM-YYYY)

Exception to OST: you need perms only one either org name or family name to take account of the fact that the web app has a single field for orgname/surname.

If permissions checking is not bypassed, and no provider role type is supplied then the user must have permission on a data element for all role types (that they want to query), for all USED Data Sets,AND all qualifiers [only if you haven’t specified the qualifier to use – if you have then you perms only one the one you specified] (e,g. for an address) in order to use that data element as a query criterion. For example, you must have permission on the Business Contact Address City for HA1’s data and for HA2’s data in order to prevent the role type from being eliminated from the list