Unet

Questions & Answers

UNOS is committed to providing clear and useful information about the redesign of DonorNet® and is continuing to gather feedback from various member organizations to ensure its success.

If your question isn't included here, please contact us so we can help.

Technical

Phase 1

Phase 2

Archives


What is the recommended RAM for the laptop?

The application requires 128 MB of RAM at the very least. 500 MB or more of RAM will provide the best performance.

For the hand held devices, would a Smartphone suffice rather than a Blackberry or Treo?

There are a number of mobile device types that are compatible with DonorNet. At a minimum, your chosen mobile device needs to have access to an e-mail account and a minimum screen resolution of 300x300 to ensure maximum legibility. Although the application will render on a smaller resolution, it will be difficult to read and interpret the information.

Is there any kind of write up that discusses the benefits of using a Treo over a Blackberry?

UNOS does not favor one over the other. The system will work as long as the mobile device has access to an e-mail account and a minimum screen resolution of 300x300.

What if we don't currently have a data system?

UNOS encourages every OPO to have a data system, regardless of whether the OPO purchases an off-the-shelf system or builds it themselves. The OPO's data system should permit the OPO to capture the data on-site and send it electronically to DonorNet. OPOs can also enter data manually into DonorNet.

Do OPOs need to develop an electronic donor form and buy laptops for everyone to replace the faxed written form? If so, will we be able to uplink data if we have it in an electronic donor form?

We are encouraging every OPO to have a data system whether it is developed in-house or purchased so that data can be entered at the patient's bedside into your data system (via laptop) rather than handwriting it and entering it later. This can increase potential transcription errors. Most of the data collected in DonorNet® should link up consistently with what you are collecting. Use the data element spreadsheet that we posted as a guide. It gives you the field name, acceptable data ranges, units of measure, and more. In the current system, the most prevalent complaints we receive involve the amount of time to fax or receive a fax from the system, the lack of uniformity of the various donor forms, and the legibility of the fax copy.

What are the new data exchange requirements so we can make an informed decision during our budget process about systems that easily interface with DonorNet?

The new DonorNet® will accept manually entered donor data or data from an OPO's data system via a simple text file upload. This process will accommodate any type of data system that can generate a delimited, flat text file in XML format. If you are considering a vendor/in house solution, ask if it supports data exchange via XML.

Does UNOS have a list of "approved" data system providers?

It is not UNOS' policy to endorse any data system providers.

What OPO data systems will be able to provide data exchange to the new DonorNet®?

Any system that can provide data in XML format will be able to exchange data with DonorNet. XML is a simple, flexible data format for structured documents on the Web.

If the Data Dictionary is up to date, is the file structure illustrated by the XML sample files still valid, or are the Data Dictionary Form Type categories more accurate?

The Data Dictionary is up to date and more accurate. The sample files are just to help developers get started with some basic format and syntax.

Is it correct to assume that all fields in the Data Dictionary are required?

No, the majority of the in the data dictionary are optional. Currently don_id, dates and remote_row_key are required for all XML tables but some conditions do exist for requiring more information for an upload.

How do I fix Data Dictionary errors?

Most errors you receive are probably range errors, meaning a value you have entered is out of range. Check the Data Dictionary to help you fix these issues.

Why does a file that worked a week ago not work today?

The schema or the data dictionary may have been updated. Check the documentation and verify that the schema has not changed.

I downloaded the xml from the download page, made a change to a field, and now I am getting several errors when I try to upload the changes. What do they mean? Why do they occur? How can I fix them?

Please review the errors as they relate to the information provided to you in the online data dictionary and online documentation on how to trouble shoot different business rules as they relate to the data being uploaded.

The DonorNet2007.net site's Technical FAQ makes reference to "a delimited, flat text file in XML format" when answering a question regarding data exchange requirements - can this be clarified? We're not sure what is intended here – XML or flat file?

At the present time DonorNet only supports UNOS native XML format. UNOS will support flat file as well as HL7 XML formats at a latter date as part of our up coming patient management system infrastructure. This infrastructure has yet to be given a delivery date but keep informed with updates posted on our DonorNet2007.net public site for any up coming information when it becomes available.

What is a remote row key, and how do I get one?

A remote row key is a unique identifier that is assigned by the process that inserts the donor record or related donor data records to ensure the data is unique to that row across physical system boundaries. At the point the row is added to DonorNet® or a remote system, the GUID is used to ensure that the new data will port between systems and have a unique identifier assigned by the agent that initiates the storage event. This way data can be exchanged freely and reconciled freely based on this remote row key.

What does "The key sequence...in Keyref fails to refer to some key. An error occurred at, (80, 4)." mean?

Check your data for space issues.

How do I fix "...does not have a value for the column [remote_row_key]"?

Insert a GUID into the xml for the field in question. This GUID value must be stored on your side with this row of data to create the link between two systems to ensure your data is always unique. A Globally Unique Identifier or GUID is a pseudo-random number used in software applications. Each generated GUID is "statistically guaranteed" to be unique. This is based on the simple principle that the total number of unique keys ( or ) is so large that the possibility of the same number being generated twice is virtually zero.

Will DonorNet users be able to correct validation errors through a user interface in the online application or must invalid data be corrected in the XML file and then re-uploaded to DonorNet?

Validation errors should be corrected through the users system. It is recommended that validation of the data take place on the users system before its uploaded and then validated in DonorNet.

Is there a Web site where developers can upload and validate test or sample XML files is already available? Is there information on how to use this test harness is posted on the DonorNet2007 Web site?

The test site is available for vendor and external OPO verification of any interface development for UNOS public interfaces. Please e-mail us for a user id password to our demo site for your testing purpose. This site is available for OPOs as well as vendors.

Will DonorNet accept submissions for multiple donors within the same XML file?

No, currently a user must be logged in and have the user interface open to one single donor in order to upload data.

Are all sections of the XML file required? If not, which ones are optional?

Only don_Id, dates and remote_row_key are required for all XML tables but some conditions do exist for requiring more information for an upload. Please reference: http://www.donornet2007.net/ContentDocuments/DonorNet_Required_Fields.doc for information on the conditions of parent and child field requirements.

Is the data and process to be collected through DonorNet is in addition to, not a replacement of the Deceased Donor Registration (DDR) submission process?

The data submitted through DonorNet pre-fills some of the fields on the DDR form but is not a replacement of the DDR submission process.

Does DonorNet provide a tool to check both the XML formatting (correctness) as well as the validating the individual values? Does this tool implement the data dictionary rules as posted on the DonorNet2007 Web site?

Yes, there is a tool that checks to see if the XML is in the correct format in order for the upload to process correctly. If the XML is formatted correctly, the tool will valid the data supplied by the user and report back any validation errors that are encountered. The data dictionary posted on the DonorNet2007 Web site reflects the most current validation rules used in both the XML upload process as well as the DonorNet® user interface.

What steps are envisioned before the process of uploading data from an OPO's system into DonorNet® will be an automated "push" (i.e., where the OPO user will simply click a “send via XML” button on the OPO’s technology system and that will deliver the data via XML?

At present, our contract with the government restricts us to manual file exchange processing. We are working on ideas that will enable us to offer a more automated interface such as a Web service or GET/POST interfaces that will enable OPO systems to interchange data more freely. Currently no timeline for this type of interface exists.

The current manual "pull" mechanism for uploading donor information via XML encourages (perhaps even requires) that the source file exist on the user's client system. Given that this may be a laptop or even a "borrowed" system at a hospital, this seems to open a significant security risk (the user needs to secure their system, there needs to be a process in place to delete previous files, etc). Is there guidance on how to keep this process secure? Is there documentation on what is acceptable in the file text box?

It is the responsibility of the OPO to secure all data they download just as it is the responsibility of the OPO to keep all data secure they are viewing while actively logged into DonorNet.It is recommended that files be deleted after the OPO system has processed the download. You can refer to a share on a server as in the case of your example. The upload and download will work with any folder location the OPO user has access to save or read files on the OPO system.

How does data exchange work?

New data exchange technologies will enable users to easily send data from an OPO's data system to DonorNet, which will save coordinators redundant data entry. It also improves data accuracy and readability, reduces potential errors and can help streamline workflow processes for OPOs. To assist members with data exchange, UNOS will provide access to tools such as file layouts, data dictionary components and business rules. Specialized technical support will also help members with data exchange. UNet will also support file mapping utilities and database linking capabilities with other systems.

How will data be inputted?

Just as in the current DonorNet application, certain basic data must be entered in the system to obtain a donor ID. Additional donor data (enough to run a match, make an offer and fulfill Policy 2.2 requirements) will need to be entered manually or imported into the system electronically. In addition, new donor records will include more than 200 new, optional donor data elements to further describe the potential donor.

Please verify the exact steps required for initial file generation in DonorNet and assignment of the Donor ID.

A donor can only be added to the DonorNet system by using the native user interface. Four data fields are required to add a donor to the system. Once a user enters a new donor a second user must log in and verify the ABO of the donor before any matches can be run or upload of donor data.

The fields required add donors to the system are:

  1. OPO (system field based on login)
  2. Donor hospital name
  3. Donor last name
  4. Ethnicity/race
When is it anticipated that the list of required fields will be finished and locked down?

Currently don_Id, dates and remote_row_key are required for all XML tables but some conditions do exist for requiring more information for an upload. Learn more >>

What is the complete list of fields wherein there is a conflict between AOPO character notation and DonorNet numeric notation? Can we get a document illustrating how these values map up?

Please refer to the data dictionary for character and numeric notation for DonorNet fields. We are making changes to quite a few field types as part of phase 2 (making them text instead of numeric or lookup values) based on member feedback.

What's the expected frequency of change for DonorNet, either for new or changed data content as defined in the schema or for the validation rules imposed on individual data items?

UNOS will work with the member and committees to ensure the data collected supports the goals of the policy. A protocol has been developed for add/removing data elements as well as changes to look-up tables and business rules. This protocol will be communicated and published for member and vendor consumption.

Since vendors will be playing an important role in supporting OPO's in meeting these new requirements what mechanism (such as demo site user ids) will be put in place to allow vendors to test their software for compatibility? To maintain the OPO as the "intermediary" between DonorNet and the OPO's technology provider creates high levels of inefficiency, confusion and delay, all of which can threaten a successful DonorNet 2007 implementation.

The test site is available for vendor and external OPO verification of any interface development for UNOS public interfaces. Please e-mail us for a user id password to our demo site for your testing purpose. This site is available for OPOs as well as vendors.

Each organ type appears to have unique required fields on the Web interface (when requesting a Match Run). We understand from discussions that these requirements are still being changed, but for testing purposes, we need the current list of specific Match Run/Organ Offer requirements for each organ? (Preferably from an XML schema standpoint so that we can ensure that required information has been included when importing donor information via XML.) Also, what is the process for finalizing (for the DonorNet2007 deadline) the Match Run/Organ Offer requirements for each organ?

The data elements required for a match were not changed as a part of the DonorNet project. Note: all policy 2.2 data elements will not be required prior to running a match.

Match Results currently are exported as flat file (tab delimited) text files. When will Match Results exports also be available to OPOs as XML? Is there a timeline for this important functionality?

We are planning on converting all UNet imports and exports to XML but UNOS does not have an official date for this type of interface to be made public.

When simultaneous notification is implemented, how many centers will be notified of a donor at one time?

A working group of the Operations Committee is developing guidelines for the number of simultaneous offers made based on donor characteristics. The OPO will always have discretion over how many offers can be made in a particular situation.

OPO coordinators will be able to choose the range of local centers to contact at once. For example, the OPO coordinator will be able to send notification to transplant centers from sequence numbers 1-5, or 1-10, etc. For new matches, the starting sequence number is always 1. For existing, open matches (those into which placement details have already been entered), offers can be made from the first sequence number that does not yet have any organ offer (PTR) data entered. The OPO coordinator can always specify the ending sequence number. This flexibility allows the OPO to make the best decision for its area based on experience and the donor's characteristics.

OPO coordinators will be able to choose the range of centers to contact at once that are within the notification limits set up in the system. OPOs will have the flexibility to set their own notification limits for their local centers. However, notification limits to non-local centers will be system-defined and enforced by the system.

At the present time, notifications to non-local centers are limited to notifying up to 5 centers at once for pre-recovery organs, and up to 10 centers at once for post-recovery organs, as recommended by a working group of the Operations Committee. These limits will be adjusted, as required, over time.

Notification limits are "rolling," meaning that if the OPO sets a limit of notifying 5 local centers, at any given point in time, up to 5 local centers may have pending responses to organ offers. Thus, if the OPO is waiting to hear back from 5 local centers already, the OPO will not be able to send out another notification to another center, until one of the centers responds for the candidates that have been notified.

Is there a back-up when the internet goes down?

At minimum, notifications must be sent to one voice device and one text device. When systems are down, the back-up method will always be direct conversations between coordinators. Also, the UNOS Organ Center is always available to provide assistance in these situations.

Will the simultaneous notifications go only to transplant centers or can OPOs be notified as well?

The new design will allow transplant centers to designate and manage their own contacts, which may or may not include members from the local OPO.

In the event there are 30 multi-organ donors occurring simultaneously in the country, will every transplant center that has a patient who matches be simultaneously "electronically" contacted for all donors for which they match?

The full match list is not contacted for every donor. Similar to the current practice, the OPO coordinator will control the number of patients down the match to notify with an offer depending on the type and condition of the donor. For instance, on an 18 year old donor with no medical issues, you may only want to send notifications to only a few patients/centers. Whereas for a 65 year old hypertensive donor, you may want to send 25 offers simultaneously. This type of system may also encourage transplant programs to closely examine their listing criteria for each of their patients to prevent getting organ offers they would not consider for a given patient.

Will the organ offer notification include everyone on the transplant team?

No. Each individual transplant team will define who is on call and who should be notified with organ offers. In some cases, it will be a coordinator and in others, a physician or surgeon.

If an OPO has an existing contact management system for their related transplant centers, how will OPOs be able to upload this existing contact information to DonorNet? If so, will an XML/file upload function be available? Having OPOs maintain two sets of contact information in their own system and also in DonorNet is impractical.

No import interface exists for the UNOS contact management module. Please make any recommendations to the DonorNet2007.net site for a request to have one added to the new system and the request will be evaluated.

Yes. Please see the attachments below for past details.

Share Your Feedback

Feedback from the transplant community is essential to the success of the DonorNet® redesign. Your feedback will help guide the design and development of parallel notifications. E-mail us now »