bloodnet – lis interface web service apis specification · bloodnet – lis interface web service...

BloodNet – LIS Interface Web Service APIs Specification

National Blood Authority Version 2.02

LIS Interface Web Service API Specification

Version: 2.2



Version Control

Version Control

Version Revision Date: Revision Description

1.0 1 Jun 2012 Initial version.

2.0 3 May 2013 Minor updates to format and included reference values in the Supporting Information section.

2.1 2 April 2014 Minor updates to reference values, format and graphics.

Updated Items List

• Receipted Issue Notes Service Update • Real Time Inventory Levels Services Update • Fate of Unit Services Update • Amendment to Entity Diagrams

o Amended diagrams o Attributes removed o Legend added o Root Contract and Contract Displayed

• Attributes amended and redisplayed in alphabetical order.

• Addition to Enumerations – RhBloodGroupPhenotype

2.2 20 June 2014 Minor updates to reference wording values, format and graphics.

Updated Items List

• Extended attribute remove mandatory elements • Request Contract correct wording • GetReceiptedIssueNotes Response Contract attributes

mandatory elements removed • ReceiptedIssueNoteLine UnitVolume correct wording • Update ComponentID and ProductId mandatory

wording



Creative Commons

With the exception of any logos and registered trademarks, and where otherwise noted, all material presented in this document is licensed by the NBA under a Creative Commons Attribution 3.0 Australia (http://creativecommons.org/licenses/by/3.0/au/) licence. In essence this licence allows you to copy, communicate and adapt the work, as long as you attribute the work to the National Blood Authority and abide by the other licence terms.

The details of the relevant licence conditions are available on the Creative Commons website (accessible using the links provided) as is the full legal code for the CC BY 3.0 AU licence (http://creativecommons.org/licenses/by/3.0/au/legalcode).

The content obtained from this document or derivative of this work must be attributed as the National Blood Authority BloodNet LIS Interface Web Service API Specification Version 2.2.

http://creativecommons.org/licenses/by/3.0/au/

http://creativecommons.org/licenses/by/3.0/au/legalcode



Contents

1 Introduction ..................................................................................................................................... 6

1.1 Purpose of Document.............................................................................................................. 6

1.2 Scope ....................................................................................................................................... 6

2 Overview of LIS Interface ................................................................................................................ 7

2.1 Initiation of Requests .............................................................................................................. 7

2.2 Product / Component Exclusion .............................................................................................. 7

2.3 Product/Component inclusion across more than one LIS ....................................................... 8

2.4 Product / Component Substitution ......................................................................................... 8

2.5 Product/Component Not Registered in BloodNet .................................................................. 8

2.6 Supplier Exclusion .................................................................................................................... 8

2.7 Releases, Upgrades and Support for Legacy Versions ............................................................ 9

2.8 Planned and Unplanned Downtime ........................................................................................ 9

2.9 Errors and Faults .................................................................................................................... 11

2.10 Communicating Processing Errors to LIS Administrators ...................................................... 11

2.11 Time Zones ............................................................................................................................ 12

2.12 Handling of Reference and Lookup Data ............................................................................... 12

2.13 Change Control for Service Definitions ................................................................................. 12

2.14 Handling of Product Codes and Lot Numbers ....................................................................... 12

3 Web Service Definition .................................................................................................................. 15

3.1 Introduction ........................................................................................................................... 15

3.2 Technology ............................................................................................................................ 15

3.3 Credentials and Authentication ............................................................................................ 15

3.4 Services .................................................................................................................................. 15

4 BloodNet Web Site ........................................................................................................................ 19

5 BloodNet Lab Systems Services Data Structures ........................................................................... 20

5.1 Introduction ........................................................................................................................... 20

5.2 Common Data Element Members ......................................................................................... 20

5.3 Extended Attribute Common Data Structure ........................................................................ 21

5.4 Get Receipted Issue Notes .................................................................................................... 23

5.5 Acknowledge Receipted Issue Notes .................................................................................... 43

5.6 Fate of Unit ............................................................................................................................ 46

5.7 Fate Of Unit Episode .............................................................................................................. 63



5.8 Update Real Time Inventory Levels ....................................................................................... 83

5.9 Enumerations ........................................................................................................................ 88

6 Supporting Information ................................................................................................................. 90

6.1 Data Element Structure ......................................................................................................... 90

6.2 Name ..................................................................................................................................... 90

6.3 Synonymous Name ................................................................................................................ 90

6.4 Definition ............................................................................................................................... 90

6.5 Source Standard .................................................................................................................... 90

6.6 Data Type............................................................................................................................... 90

6.7 Representational Class .......................................................................................................... 91

6.8 Field Size Maximum ............................................................................................................... 92

6.9 Representation Layout .......................................................................................................... 92

6.10 Domain Values ....................................................................................................................... 92

6.11 Guide for Use/Examples ........................................................................................................ 92

6.12 Mandatory ............................................................................................................................. 92

6.13 Implementation of Data Types .............................................................................................. 92

6.14 References and Standards ..................................................................................................... 93

6.15 Interpretation of the GS1 Related Standards ........................................................................ 93

6.16 Technical references for connecting to WCF ........................................................................ 94

6.17 Example Product Packaging and Codes ................................................................................. 95

6.18 Reference Table Values ......................................................................................................... 95

6.19 About BloodNet ..................................................................................................................... 97

6.20 Definitions, acronyms and abbreviations .............................................................................. 98



1 Introduction

1.1 Purpose of Document The purpose of this technical document is to describe the specifications for the BloodNet Laboratory Information System (LIS) interface. It is intended for software developers and LIS Administrators who are integrating with the BloodNet LIS API for exchanging information with BloodNet.

1.2 Scope The BloodNet-LIS interface covers 3 broad categories of operations:

1. Services to download issued line item data from BloodNet orders to LISs for all units issued by the Blood Service to the relevant laboratory, which replaces the process of laboratory staff manually entering inventory into the LIS.

2. Services to upload real time Inventory Levels of blood components and blood products stored in a laboratory from the LIS to BloodNet to enable real time management of the national inventory, particularly in times of inventory shortage and to remove the requirement for manual data entry of this information into BloodNet.

3. Services to upload data from the LIS to BloodNet relating to the status of units contained in the laboratory inventory, specifically when a unit is discarded, transferred to another laboratory or transfused. This will inform supply planners and hospital staff in relation to the efficient operations of the national supply chain, and will replace the manual data entry processes currently undertaken by the majority of laboratories nationally into the Fate Module in BloodNet.

Figure 1 LIS Interactions in context of information flow between BloodNet/Blood Service/LIS



2 Overview of LIS Interface 2.1 Initiation of Requests All service endpoints are provided as part of BloodNet. Any requests will be initiated by the LIS.

2.2 Product / Component Exclusion LIS systems can be configured not to accept items containing a particular product or component. For example, inventory for a Facility may be managed via two separate LIS systems – one for products (such as a pharmacy system) and another for components. Another example is that it is possible that your LIS does not accept a particular product due to the format of the lot number.

In this situation it is possible to configure a LIS not to accept a certain products or components. This in turn influences the treatment of the data that BloodNet provides for that LIS and also the data that is expected from that LIS.

The treatment of data if a LIS excludes a certain product or component is:

1. Any information containing that product or component is not sent to the LIS when requesting Receipted Issue Notes.

2. To indicate that real time inventory levels for the product or component will not be provided from the LIS.

3. To indicate that fate for the product or component will not be provided by the LIS.

Affected behaviour when invoking Get Receipted Issue Notes will be:

4. Line items for units of that type will be dropped when providing issue note information. 5. Acknowledging issue notes will mark those units as acknowledged. 6. Issue notes that only have items that are excluded will not be returned and will be marked off as

acknowledged automatically.

Affected behaviour when invoking Real Time Inventory Levels will be:

7. Real time inventory data for this type of unit will be obtained via another LIS if possible or will need to be provided manually via the existing processes by entering the information into a routine order.

8. Real time inventory data for this type of unit will be ignored if provided.

Affected behaviour when invoking Fate of Unit will be:

9. Fate of unit or status change of unit will be ignored if provided.



2.3 Product/Component inclusion across more than one LIS BloodNet supports more than one LIS-like system for each facility to provide limited support for considerations mentioned above in 2.2 Product / Component Exclusion. As the functionality offered is limited, BloodNet only supports the same Product or Component in one LIS.

If a Facility has the same inventory composition in more than one LIS the Facility will be responsible for ensuring the data is brokered correctly before reaching BloodNet. In some situations this could be as simple as not passing data from one LIS and replicating the Issue Note data out to several LISs once performing Receipting in the brokering system. Other situations may require more complicated aggregation and fating rules.

When a Facility has a second LIS added the default configuration will be to exclude all product and components from that LIS. From here the products and components that should be available in that LIS would have to be excluded on the first LIS before being added to the second. The recommendation is to add the primary LIS to BloodNet first to limit the amount of reconfiguration needed.

2.4 Product / Component Substitution There may be occasions where a substitution of one component or product has been made for another. BloodNet will not perform any substitution from the supplier side or when information is passed back from the LIS.

2.5 Product/Component Not Registered in BloodNet There can be instances when products that are distributed have not yet been published in BloodNet. This is primarily due to required information still being gathered and in a worst case scenario is usually resolved soon after the product has started being distributed but could also be due to a supplier changing key product information without informing the NBA.

Products that are not registered in BloodNet can still be receipted and will still be available to the LIS in calls to Get Receipted Issue Notes. Additionally these products should still be returned when Fate of Unit is provided and in Real Time Inventory Levels.

Products that are not registered in BloodNet will be handled without error but will notify the NBA and information that would normally be expected regarding a component or product may not be available.

2.6 Supplier Exclusion At present BloodNet contains information from only one supplier. It is understood that a LIS may only have support for a single product list or supplier product list.

In order to improve compatibility with LISs that cannot handle multiple suppliers a LIS/Facility can be only be configured to support a single supplier.



2.7 Releases, Upgrades and Support for Legacy Versions Any changes will be made to new versions of the data objects via a new endpoint. Old versions will be supported for a period of time not less than twelve months.

If the Lab Systems Services are running in Offline Mode the core methods will continue to operate without error however non-core methods will return a BloodNet Offline exception.

Releases will be performed to minimise downtime where possible.

2.8 Planned and Unplanned Downtime There are several foreseeable situations where there will be downtime. The key scenarios are:

10. Lack of internet connectivity between BloodNet and LIS. 11. Service unavailability from the LIS side. 12. Service unavailability from the BloodNet side. 13. Backend server maintenance. 14. Releases of other BloodNet systems.

Scenario 1 - No internet connectivity between BloodNet and LIS This scenario covers any fault in the internet beyond the control of the NBA or the network the LIS is on.

Under the conditions of Scenario 1 the LIS would have to queue messages to be sent to the Lab Systems Services otherwise data loss would be expected.

If queuing is not performed any changes to the fate of a unit would have to be entered into BloodNet via the web interface when the system was available again.

Issue Notes and Receipted Issue Notes (depending on where the failure occurs) will continue to build up in BloodNet (assuming the issue notes emailed to BloodNet are received before they exceed any send timeout). It would be expected that the LIS would continue to support processes that are currently in place- specifically any receipting and quarantining. It is then critical that a LIS supports a process to acknowledge receipted issue notes without loading any data, or allowing that data past quarantine.

Real time inventory levels can tolerate a greater level of loss however if the connection between BloodNet and a LIS was to be unavailable for an extended period of time the inventory levels would have to be entered manually into routine orders as per the current arrangements. To assist with identifying this issue details about the last time inventory information was provided are provided on the routine order pages.

Scenario 2 – Service unavailability from LIS This scenario covers situations where the LIS is completely unavailable, or where the Client is unable to properly perform processes relating to the interaction with the Lab Systems Services.



When the LIS is completely unavailable it is expected that existing process for handling downtime of the LIS are followed. Fate of units and inventory levels can be entered into the BloodNet facility web site. Once the LIS becomes available again and information is entered into the LIS it is understood that the information would probably be entered into the LIS and that some duplicated information would be provided to the Lab Systems Services. BloodNet will endeavour to ensure the consistency of this data however the fate of some of the units may change.

As in Scenario 1 receipted issue notes will continue to build up in BloodNet. See Scenario 1 for more details of how this should be handled.

When the Client is unable to interact with BloodNet data should be provided in the facility web site and the LIS. The information is not required to be re-transmitted to BloodNet once the Client is operational. If the Client is not capable of filtering out the data, BloodNet will endeavour to ensure the consistency of this data however the fate of some of the units may change.

As in Scenario 1 receipted issue notes will continue to build up in BloodNet and refer to Scenario 1 for details of how this should be handled.

Scenario 3 - Service unavailability from BloodNet This scenario covers any unexpected infrastructure or major software fault in the NBA’s software or infrastructure.

The conditions that apply under Scenario 1 also apply to Scenario 3 with the additional requirement for real time inventory levels in the event of an extended outage.

Real time inventory levels can tolerate a greater level of loss however if the system was to be unavailable for an extended period of time the NBA would require the inventory levels to be provided via an alternate means such as a manual order in BloodNet. Regardless of whether inventory information is queued and provided at a later time it is expected that manual orders would include the inventory information where appropriate.

Scenario 4 - Backend server maintenance. This is dealt with via durable messaging and the concept of Offline Services – see below for details.

Scenario 5 - Releases of other BloodNet systems. This is dealt with via durable messaging and the concept of Offline Services – see below for details.

Offline Services Core Lab Systems Services will be designed around an offline service model. This allows for maintenance work on BloodNet to be performed with minimal effect on Clients.

Offline Capable Services (OCS) can be configured to run online or offline based on a configuration setting. When offline the OCS will return only information that can be determined outside of the core BloodNet system. Where the client expects information to be returned empty lists or results should be returned. Services that will be Offline Capable would generally be services that provide



information from BloodNet to the Lab Clients. An example of an OCS is the GetReceiptedIssueNotes service. Upon calling this service an empty list of Issue Notes would be returned.

Durable Message Services would be any service where data was provided to BloodNet. Durable Message Services allow messages to be posted and queued for later processing. This provides both a method for high performance and timeout avoidance, and a way for data to be posted while BloodNet core components are offline without losing data or affecting the Lab Clients service.

Other Utility Services will not use OFS or Durable Messages and can be expected to fail with a BloodNetOffline exception if called while the site is offline.

Before any set of actions is to be performed where there is a dependency on services that are not offline capable the client should check whether the services are online or offline and only attempt the action if the services are online. BloodNet services will be taken offline based on maintenance Windows identified in any communication to BloodNet users. This, however, does not help automated systems and it is possible this change occurs half way through a client operation (consisting of several calls) therefore there is still a need to appropriately handle BloodNetOffline exceptions in all calls.

2.9 Errors and Faults Calls to methods will fail silently except in a few cases. The reason for this is that it allows the LIS to remove its need to manage errors in processing the data at the BloodNet end or deal with handling of invalid data. Failures will be recoded in BloodNet and, where appropriate, be made visible to users within BloodNet and through email notification to nominated contacts. Examples of errors that will be reported and returned to the caller include:

• Insufficient permissions or invalid client (LIS) • Data format errors • Channel failures

Examples of errors that will not be reported include:

• BloodNet Facility data not managed by the LIS • Products not supported by BloodNet • Internal errors processing the request

Hiding errors that are not important to the client allows greater scope for changing the internals of the solution without breaking clients.

2.10 Communicating Processing Errors to LIS Administrators In the situations that data for there is an error during processing. These errors be monitored by the NBA and forwarded to LIS administrators to allow them to analyse and correct any errors that are occurring with the data that they are providing back to the NBA.



2.11 Time Zones BloodNet operates around Australia for users in different time zones. Further to this, times are an important part of the data within BloodNet.

In order to produce consistent results any time value sent or received between the LIS and BloodNet will be in UTC.

Within the BloodNet website all times are adjusted for the facilities primary time zone.

Any data sourced from a system outside BloodNet such as the ReceiptedIssueNote DespatchDateTime are not adjusted by BloodNet. This information is provided by the supplier in a format decided by the supplier.

2.12 Handling of Reference and Lookup Data When a LIS is integrated into BloodNet they are provided a list of required reference data values that they are required to integrate or map within their system for use in service calls. When reference data values are updated they will be provided to the LIS administrators via email.

2.13 Change Control for Service Definitions Service definition changes will be limited to critical updates and after appropriate consultation has taken place.

Large changes will be implemented via versioned service contracts, messages, and endpoints.

2.14 Handling of Product Codes and Lot Numbers Product codes and lot numbers are vitally important to identification of the correct unit to perform an operation on in both the Receipted Issue Notes methods and the Fate of Unit methods. Frequently this information is represented in one or more barcodes and/or written on a product.

There are inherent complications in this data due to several factors including, but not limited to:

• Data being stored in two or more different formats such as text on the product, a barcode or barcodes on the product, and information presented on the Issue Note.

• Different information presented in each of the above places. • Differing barcode standards between products. • Limited handling of information encoded in a barcode in the different applications (including

BloodNet). • Differing scanner configurations. • Different product codes on Issue Notes than provided on the product package. • Not knowing which barcode represents which field. • Scanning the wrong barcode into a field. • Different product configuration in each LIS. • Information that is not relevant in the form of text or barcode in the product. • Changes to any of this data in the future and the impact it has on the system.



• Differing interpretations of the data presented. • Different product codes even used by the manufacturer for the same product.

The section Example Product Packaging and Codes provides some examples of the differing data that could be encountered.

The information provided to BloodNet in the Issue Notes is up to the supplier. The supplier provides their own product codes and determines the lot number provided by the manufacturer unless they are also the manufacturer and must then provide both the product code and lot number.

Following are some examples of the data included in the lot number:

• Components have the “d” removed from the beginning and end of the donation lot number • CSL products usually do not have the “C” removed from the beginning and end of the donation

lot number. • There are some indications of a product code being built into the barcode used on CSL product

(the first 6 numbers) with the rest being the actual lot number. • Xyntha is an example of where the lot number scans with a 0NNNNN but the text lot number is

FNNNNNN – the issue note uses the text version. • The Blood Service also define an additional level of encoding on top of their product codes for

components – specifically they include a0 as the start sequence and 3b and the stop sequence of their otherwise Codabar barcodes.

• The Blood Service product code for Octagam 5g/100ml is 84004, the manufacturer’s code is OC2000 and the GTIN is 09006477840034.

It is possible for the lot numbers provided by the Blood Service to be incorrect. The Lot number of products could potential include information like expiry date or a product identifier. This is a known issue and is being addressed by the Blood Service.

Given the way in which these codes are determined, and in order to support multiple suppliers, a Product or Component in BloodNet, there are several things that need to be considered. BloodNet may have different supplier product codes for the same product but should be able to manage the set of lot numbers for the same product from different suppliers. Product codes and lot numbers on product packaging are determined by the manufacturer, and as they are determined by the manufacturer any barcode format could be used. Barcodes could contain alphanumeric characters.

BloodNet approaches this in several ways.

The Lot Number or Donation Number provided by the Supplier on the Issue Note is left as is. No start and stop codes are removed and the data, correct or incorrect is provided as is. BloodNet will also provide a Derived Lot Number which will be the Lot Number with an appropriate algorithm run over the top of it based on the products configuration to extract the data. For example CSL products use Codabar – the start and stop codes, as defined in the Codabar standard will be removed. For products with a GS1-128 or similar code will have the Lot Number extracted where the application identifier 10 can clearly be determined (it starts with a 10 or any other fixed length application identifiers once removed leave an application identifier of 10 followed by some character sequence). When a parse rule fails for the Issue Note Line the Derived Lot Number Parse Error flag is set to true and the Derived Lot Number field is not set. If the data in the issue note passes without requiring any



modification the Derived Lot Number and the Lot Number fields will have the same data and the Derived Lot Number Parse Error flag will be set to false.

For future use BloodNet will pass a Barcode field with each Issue Note Line which is intended to record the entire “primary” barcode for an item. This is not provided to us on Issue Notes at present and therefore this will not be populated yet. When this does become available the issues parsing and with scanner configurations still exist but improved consistency will limit the issues we have.

BloodNet will also include its known product barcode configuration via the GetSupplierProducts method. This allows for a better understanding of the methods we are using for parsing the Lot Number for any product type. This can also be used with Get Candidate Products for Lot Number method to diagnostically identify a Product within BloodNet. These methods do not operate on Components.

Any calls returning data to BloodNet should provide a lot number without start and stop codes based on the human readable version of the barcode. BloodNet may perform some cleaning on the value in order to find an appropriate match. For example the BeneFIX printed lot number starts with an F but the scannable lot number starts with a 0.

BloodNet deals with different product codes per supplier by using BloodNet product codes as the key in all calls throughout the system. So long as a LIS returns the appropriate BloodNet Product ID batch searches can be performed across records from all suppliers.

Any calls back that fail to find a match will be indicated on the web site for identification. The messaging system will also be used for keeping these failed requests for diagnostics are replays if required. LISs can also re-fate the same unit with changed barcodes if they want but BloodNet does not provide a system to determine which units failed to get identified in a fate episode programmatically.



3 Web Service Definition 3.1 Introduction This specification describes the Web Service API interface definition for BloodNet-LIS interfaces. This interface is used by the client application and windows service to communicate with BloodNet.

3.2 Technology The BloodNet Lab Services are based upon Windows Communication Foundation.

3.3 Credentials and Authentication The credentials provided will be specific to a LIS installation thereby allowing a LIS to support several laboratories (e.g. hospitals) or a single laboratory, based upon the configuration of the LIS.

Authentication will be provided via username/password.

All service methods require a request object and return a response object. This approach helps with standardising request/response values that are required across the board.

3.4 Services There are 3 functional points supported by service methods in the LIS services:

1. Getting Receipted Issue Notes 2. Providing Real Time Inventory Levels 3. Providing the Fate of Units

To ensure the integrity of the data collected by the NBA, service 1 (Getting Receipted Issue Notes) will only be enabled by the NBA for those laboratories that are fully populating and implementing services 2 (Providing Real Time Inventory Levels) and 3 (Providing the Fate of Units).

Receipted Issue Notes GetReceiptedIssueNotesResponse GetReceiptedIssueNotes(GetReceiptedIssueNotesRequest)

AcknowledgeReceiptedIssueNotesResponse AcknowledgeReceiptedIssueNotes(AcknowledgeReceiptedIssueNotesRequest)

The Receipted Issue Notes service provides the ability to get the individual unit details from newly receipted issue notes once the units have been receipted in BloodNet. Issue Note Lines will be returned only where they have a Received Quantity greater than zero.

A call to this method will return all unacknowledged issue notes including the full unit details for each unit on the issue note to the LIS. Following the receipt of issue notes via this method the client should make a second call to acknowledge receipt of these items. Failure to call the acknowledge method will result in the same items being returned in the next call to get unacknowledged items.



If a Facility is managed by several LISs the acknowledgement only applies to that LIS. Issue notes that have been acknowledged by one LIS will still be picked up by another.

If an issue note need to be re-posted to the LIS (to enable testing, following an outage or roll-back etc) operations are available from the BloodNet website that enable a Senior Scientist from the affected laboratory to manually reset an issue note to unacknowledged. This means that the issue note will be provided again in the next call from the LIS. Using this process, it is not possible to select individual units on an issue note to resend. All items on the issue note must be resent.

This method has a maximum number of 100 issue notes to send out in a single call to limit the resource demands of the call on both the LIS and BloodNet infrastructure. Should a large number of unacknowledged issue notes exist in BloodNet, several calls will be required to clear the backlog.

This method must not be called more frequently than once every five minutes unless there is an expectation that there is a backlog that needs to be cleared and such an approach has been approved by BloodNet Support.

Those responsible for configuring and maintaining a LIS that interfaces into BloodNet using this service must ensure that the units whose details are passed through this service are held in a receipting area electronically in the LIS until the normal group checks and other validation steps have been completed and recorded in the LIS.

Real Time Inventory Levels UpdateRealTimeInventoryLevelsResponse UpdateRealTimeInventoryLevels(UpdateRealTimeInventoryLevelsRequest) Real Time Inventory Levels Services allow laboratories to provide up to date information of their stock levels. This information is used by BloodNet to assist with stock level information required by the Blood Service when placing a routine order. It is also used by the NBA, Jurisdictions and the Blood Service to manage the national supply of blood and blood products. Inventory Levels can be provided for a laboratory or all laboratories managed by a LIS. Data will be aggregated to the Product/Component level and must only include units that are available for transfusion. For example, units that are cross-matched for a patient must not be reported in the same way as they are not normally reported to the Blood Service in current manual processes. Inventory levels for a Component with a blood group and a modifier would be considered one inventory level item. Inventory levels are not at the unit level and do not include a lot number or an expiry date. A LIS should provide updated inventory levels for all of the laboratories it holds data for at each call. Real time inventory levels must be provided every fifteen minutes unless negotiated separately with the National Blood Authority. If inventory levels for several Facilities are being provided from one LIS and the calls only include one Facility then several consecutive calls can be made until the entire inventory of the LIS has been provided. The data provided by this method is not validated in BloodNet against agreed inventory levels, issued, receipted or fated units and will therefore allow data to be provided that is improbable when considering the other data sets contained in BloodNet.



Real time inventory data for components is expected to contain modifier information if it is to be presented in the ordering screens for the best effect. Failure to do so will only provide real time inventory levels for the basic components. Additionally if certain components and modifiers, or products are represented in the LIS by a different product type the LIS would be expected to make the conversion back into the appropriate BloodNet component modifier combination. For example thawed Fresh Frozen Plasma could be represented as a different product in the LIS while in BloodNet it would be represented as Fresh Frozen Plasma with a particular modifier, if it was to be included at all. In this case BloodNet does not include any information about thawed fresh frozen plasma so it could be dropped by the LIS.

Calls to this method will fail silently except in a few cases. This allows the LIS to absolve itself of the need to manage errors in processing the data at the BloodNet end or deal with handling of invalid data. Failures will be recoded in BloodNet and, where appropriate, be made visible to users within BloodNet and through email notification to nominated contacts. Errors that will be reported and returned to the caller include:

• Insufficient permissions or invalid client (LIS) • Data format errors • Channel failures

Examples of errors that will not be reported include:

• Data for Facilities not managed by the LIS according to BloodNet • Products not supported by BloodNet • Internal errors processing the request.

Hiding errors that are not important to the client allows greater scope for changing the internals of the solution without breaking clients.

The Real Time Inventory levels provided through this service will be displayed to users of the BloodNet website on the Routine Order Templates, indicating the date and time of the last update.

Fate of Unit FateOfUnitResponse FateOfUnit(FateOfUnitRequest fateOfUnitRequest)

FateOfUnitEpisodeResponse FateOfUnitEpisode(FateOfUnitEpisodeRequest) The fate of unit data set is provided per unit as the status of the unit changes. The Fate of a unit should be provided whenever that unit is in a state in which its Fate is determined or changed. For instance when a product is recorded in the LIS as Discarded or Transfused the service should be called providing those details. Fate should also be provided when the unit is transferred from a laboratory. The service does not need to be called when the unit arrives at the laboratory. It is assumed that the unit has arrived at the destination as soon as the call has been made.

Fate must include the facility that the product was fated at, the Donation/Lot Number, Component Type, Collection Date and Expiry Date will indicate whether the product was Discarded, Transfused, or Transferred to another laboratory.



Details of the information required when providing fate are detailed in the BloodNet Lab Systems Services Data Structures section on page 20.

Where units are recorded as discarded additional data including the location of discard and the reason for discard (matching the nationally agreed set of locations and reasons) must be provided, with an optional comments field also able to accept additional information.

Where units are recorded as transferred, additional data including the destination laboratory, its AHP code and the reason for transfer (matching the nationally agreed set of transfer reasons) must be provided.

Where units are recorded as transfused, additional data relating to the demographics of the patient and the medical condition must be provided.

In some cases the fields required in BloodNet for a fate episode may require information that is not recorded in the LIS. This can be dealt with by:

15. Modifying the UI on the LIS to accept this data. 16. Creating a departure area to allow filling in of missing data before sending response to BloodNet. 17. Translation of codes that can be put into text areas into the appropriate field in BloodNet.



4 BloodNet Web Site Changes will be made to the BloodNet Web Site to support the functions provided by the LIS Interface. These changes will include:

18. The ability to mark any receipted item for republication. 19. The ability to mark any receipted item as acknowledged. 20. The receipting screen will now record the order that an item is scanned. 21. A page showing the current inventory as provided by the LIS for a Facility and for a LIS and the

date/time that the update last occurred. 22. A page showing the current inventory as converted to a facilities customised order template for a

Facility and the date/time that the update last occurred. 23. A page showing a list of the last 100 processed unit state changes for a LIS. 24. A page showing a list of the last 100 real time inventory level requests processed. 25. A page showing the count of Issue Note Line Items yet to be processed for the LIS. 26. A page showing the last time each of the key service methods was called. 27. The issue note list will include a new Acknowledged tab to indicate when an issue note has been

acknowledged. This tab will not exist when a LIS is not configured for a facility but if it does then the flow on the issue note screen will be “Issue Notes”, “Receipted Issue Notes” and “Acknowledged Issue Notes”.

28. A Status page that shows the current status of BloodNet and BloodNet Components. The page will also show important operational messages regarding the status of BloodNet and BloodNet Components.



5 BloodNet Lab Systems Services Data Structures

5.1 Introduction This section describes the key data structures used in the BloodNet Laboratory Client Windows Service. More information on the format of the information used to define the data structures is available in the Supporting Information section on page 900.

The data structures are based on a Request and Response model where each method accepts a request object and returns a fault or response object. The request and response messages are designed as Data Transfer Objects (DTO’s) and fulfil very specific requirements for each method. This approach takes some of the coordination requirements from the LIS and reduces the complexity of troubleshooting across process boundaries but does require more complex data transformations.

5.2 Common Data Element Members There are several common data element members that share both the same name and definition within the Lab System Services. The following section provides information about these common members and the relationships between the containing data element and the members. Where these members are used the containing element will still list the member but a reference will be made to a common data element.

Deprecated

Name Deprecated Synonymous Name Definition A flag indicating that the record has been deprecated and is not available

for use. Source Standard BloodNet Data Type Numeric Representation Class Boolean Field Size Maximum 1 bit Representational Layout X Domain Values Code Description

1 True 0 False

Guide for Use/Examples Any record that is flagged as deprecated indicates that the record should not be used any ware such as in a Foreign Key relationship . Any data to be presented to BloodNet with a deprecated flag must be translated into an appropriate value that is not deprecated by the LIS before being sent to BloodNet. Deprecated records are used only for maintaining consistency historically.

Mandatory Y

LastUpdated



Name LastUpdate Synonymous Name Date Updated, Date Modified Definition The date that the record was created or last modified by a user or

business action. Source Standard BloodNet Data Type Numeric Representation Class Date and Time Field Size Maximum Representational Layout Yyyy-mm-dd hh:mm:ss.fffZ Domain Values A UTC date and time in the past. Guide for Use/Examples When a record is updated by the user this field is updated automatically.

Certain other business operations will update this value. However, some maintenance procedures could be carried out without updating this value – this would be decided on a case by case basis by the development team. When taken into consideration along with the SerialNumber this forms a method for determining whether any changes had occurred since the last call and take appropriate action if there were changes, including approval processes if data quarantining is performed.

Mandatory Y

SerialNumber

Name SerialNumber Synonymous Name Timestamp, Serial Definition A number indicating an arbitrary version of the record. Source Standard BloodNet Data Type Numeric Representation Class Serial Field Size Maximum 8 Bytes Representational Layout N Domain Values Any value valid within an unsigned 8 Byte integer Guide for Use/Examples This value will be updated any time the record is updated. The numbers

should increase in sequence until the range is exhausted however noting a change in the value would be the most reliable way to identify a change. When taken into consideration along with the LastUpdated this forms a method for determining whether any changes had occurred since the last call and take appropriate action if there were changes, including approval processes if data quarantining is performed.

Mandatory Y

5.3 Extended Attribute Common Data Structure

ExtendedAttribute



The Extended Attribute data structure is used throughout the service data structures where there is an identified possibility of changes that occur within BloodNets internal structures that could result in additional data being able to be provided by BloodNet or used by BloodNet.

For example take the situation where Suppliers start providing a new attribute on Issue Note Lines is of interest so some Facilities. Instead of waiting for a new major version of the services to be developed and deal with the cost associated with connecting to a new set of services with different definitions a minor release of the Lab Systems Service would allow this data to be transformed into an Extended Attribute and passed in along with the other response data.

The same works just as well for clients passing data back. If BloodNet allows some additional data to be entered in a Discard Episode the data can be passed back using an Extended Attribute. If it is not provided the field would be blank, if it was provided the data would be set.

It is acknowledged that this technique is not the optimum solution however given the restrictions on making major service changes this allows a highly stable service contract without sacrificing data access.

All attempts have and will continue to be made to ensure that extended attributes are not required but the flexibility they afford warrants their inclusion.

Key

Name Key Synonymous Name Definition The name of the extended attribute Source Standard BloodNet Data Type Alphanumeric Representation Class Identifier Field Size Maximum 30 Representational Layout X(30) Domain Values Any combination of letters, numbers, and symbols. Guide for Use/Examples The key is a unique value within the set to represent the name of an

additional attribute attached to the parent record. Mandatory N

Value

Name Value Synonymous Name Definition The value of the extended attribute Source Standard BloodNet Data Type Alphanumeric Representation Class Text Field Size Maximum 1500 Representational Layout X(1500) Domain Values Any combination of letters, numbers, and symbols. Guide for Use/Examples The value represents some data the additional attribute is meant to

represent. This is always untyped and presented as text but it could be meant to represent a numeric or small XML package.

Mandatory N – may be an empty string.



5.4 Get Receipted Issue Notes GetReceiptedIssueNotesResponse GetReceiptedIssueNotes(GetReceiptedIssueNotesRequest)

Request Contract The Get Receipted Issue Notes method takes an optional Facility ID. The Facility ID can be used to pull down a specific facilities issue notes if the user knows that there are receipted items to pull down. This also assists in reducing the number of duplicates pulled down by excessive user triggered events.

GetReceiptedIssueNotesRequest

GetReceiptedIssueNotesRequest

FacilityID

Name FacilityID Synonymous Name BloodNetFacilityID, HospitalID Definition The Unique Identifier within the BloodNet system for the Facility

specifically a number representing a facility defined within BloodNet. Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout N Domain Values One of the FacilityID values returned from the GetManagedFacilities

method Guide for Use/Examples Normally this value would be null. The Facility ID should be provided

only if you want to get Receipted Issue Notes one facility. This allows for user triggered get events without pulling down large numbers of issue notes that would already have been pulled down via the scheduled call.

Mandatory N



Response Contract The response contains one or many Receipted Issue Notes and nodes one or many Receipted Issue Note Lines.

ReceiptedIssueNote

Patient ReceiptedIssueNoteLine ExtendedAttribute

Modifier RFID

GetReceiptedIssueNotesReponse ExtendedAttribute

Root contract

Contract

Root contract

Contract

LEGEND

1 * 1 *

1*

1 *

1

*

1

0..1

GetReceiptedIssueNotesResponse This contract contains no attributes.

ReceiptedIssueNote

AHPReference

Name AHPReference Synonymous Name Definition A user defined code that is included on the order and the issue note. Source Standard BloodNet Data Type Alphanumeric Representation Class Text Field Size Maximum 50 Representational Layout X(50) Domain Values Any combination of letters, numbers, and symbols Guide for Use/Examples The ordering screens in BloodNet include an AHP Reference field. This

field allows for a user entered textual string to be included in the order. One the order is fulfilled the value should also be included on the Issue Note. BloodNet does not presently check to make sure this number is unique but the intent is that the value is unique for the facility.

Comments Name Comments Synonymous Name



Definition The supplier line issue note comments. Source Standard BloodNet Data Type Alphanumeric Representation Class Text Field Size Maximum 200 Representational Layout X Domain Values Guide for Use/Examples Comments are used to provide information about individual lines or the

entire Issue Note to the Facility. This field is frequently used by the supplier to indicate things such as: • How it is being transported and when it is expected to arrive (for

example which train). • Patient information. • Information to help relate this back to a record in the Facility

DespatchDateTime Name DespatchDateTime Synonymous Name DispatchDateTime, SupplerIssueDateTime Definition The dispatch date. Source Standard NEHTA eProcurement Despatch Advice, BloodNet Data Type Numeric Representation Class Date and Time Field Size Maximum Representational Layout Yyyy-mm-dd hh:mm:ss Domain Values Any date and time. Guide for Use/Examples This value represents the Despatch Date Time as defined by the NEHTA

eProcurement / GS1 Despatch advice standards. In the case of Blood Service issue notes this value contains the Date and time value presented in the header information.

FacilityID Name FacilityID Synonymous Name BloodNetFacilityID, HospitalID Definition The Unique Identifier within the BloodNet system for the Facility Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout N Domain Values One of the FacilityID values returned from the GetManagedFacilities

method Guide for Use/Examples

HealthProviderCode Name HealthProviderCode Synonymous Name AHP Code, Approved Health Provider Code Definition The AHP Code for a Facility (Hospital). If a hospital has several AHP

codes for different sections then the AHP value that was provided when the Facility was created in BloodNet.



Source Standard Blood Service Data Type Alphanumeric Representation Class Identifier Field Size Maximum 50 Representational Layout X(50) Domain Values The Blood Service Approved Health Provider codes. Guide for Use/Examples Example 51CMOD

IssueNoteID Name IssueNoteID Synonymous Name Definition The identifier assigned to the Issue Note in BloodNet Source Standard BloodNet Data Type Numeric Representation Class Identifier Field Size Maximum 4 Bytes Representational Layout N Domain Values Integers above zero Guide for Use/Examples

OrderNumber Name OrderNumber Synonymous Name BloodNet OrderID Definition In the terms of supply chain management the order that this dispatch

advice was created to fulfil. Source Standard BloodNet, NEHTA eProcurement Despatch Advice Data Type Alphanumeric Representation Class Text Field Size Maximum 30 Representational Layout X(30) Domain Values Any combination of letters, numbers and symbols Guide for Use/Examples The order number reflects the identifier of the order that the customer

placed with the supplier or distributer. In the case of BloodNet orders it will be the BloodNet Order ID. Where a valid BloodNet Order ID cannot be found and the order did originate from BloodNet the value will be an empty string or null. For orders placed outside BloodNet this would be the order number from that system and the OrderSourceSystem would be marked with the originating system. This treatment does not reflect standard GS1 treatment of this data.

OrderSourceSystem Name OrderSourceSystem Synonymous Name Definition A string representing the system an order was placed through Source Standard BloodNet Data Type Alphanumeric Representation Class Text Field Size Maximum 10 Representational Layout X(10)



Domain Values Any combination of letters, numbers, and symbols Guide for Use/Examples When an OrderNumber is present the OrderSourceSystem provides

context to identify the related order. For example if an order for units was placed within a LIS which then resulted in an order being placed in BloodNet and the BloodNetOrderID was recorded in the LIS then when the issue note that fulfilled that order was received by BloodNet and if the Issue Note was filled out correctly by the BloodService the OrderNumber would be the BloodNetOrderID that was fulfilled, or partially fulfilled, by this IssueNote. This data could then be related back to any records in a LIS.

SupplierID Name SupplierID Synonymous Name Definition The BloodNet Supplier ID for the supplier that provided this Issue Note Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout N Domain Values One of the Supplier ID values returned from the GetSuppliers method Guide for Use/Examples

SupplierIssueNoteID Name SupplierIssueNoteID Synonymous Name IssueNoteID, Blood Service Issue Note ID, Issue Number, Consignment

Note ID Definition The Issue Note Identifier provided by the supplier, for example the

Blood Service. Source Standard BloodService Data Type Numeric Representation Class Identifier Field Size Maximum 8 Bytes Representational Layout N Domain Values A unique identifier for the Issue Note as supplied by the supplier.

Presently this value will is provided by the Blood Service but will contain Issue Notes from other suppliers in the future. The uniqueness of this value must be ensured by the supplier and will only be unique within the supplier i.e. other suppliers may generate the same value.

Guide for Use/Examples

Ward Name Ward Synonymous Name Definition Chief/Supervising Scientist in charge of Transfusion Source Standard Blood Service Data Type Alphanumeric Representation Class Text Field Size Maximum 200



Representational Layout X Domain Values Any descriptive combination of letters, numbers and symbols. Guide for Use/Examples Example:

SCIENTIST IN CHARGE (000001) SCIENTIST-IN-CHARGE (000001) SCIENTIST IN CHARGE BLOOD BANK (000001) LAB MANAGER (000001) DIRECTOR OF NURSING (000001) PURCHASING OFFICER (000001)

ExtendedAttribute See the Extended Attribute common data element for detail on how this is to be used. This object can be attached to several different parents as defined in the class diagram for this message.

Key

Name Key Synonymous Name Definition The name of the extended attribute Source Standard Data Type Representation Class Field Size Maximum Representational Layout Domain Values Guide for Use/Examples See the Extended Attribute Common Data Structure

Value Name Value Synonymous Name Definition The value of the extended attribute Source Standard Data Type Representation Class Field Size Maximum Representational Layout Domain Values Guide for Use/Examples See the Extended Attribute Common Data Structure

Patient When an Issue Note Line is intended for a patient a patient may be attached to the Issue Note Line.

ABOGroupPhenotype

Name ABOGroupPhenotype Synonymous Name ABO Blood Group, Blood Group, ABO Definition The ABO Blood Group Source Standard SNOMED-CT Data Type Numeric Representation Class Code



Field Size Maximum Representational Layout Domain Values See the ABOGroupPhenotype enumeration Guide for Use/Examples

BirthDate Name BirthDate Synonymous Name DOB, Date of Birth Definition The date that the patient was born Source Standard AS 4590-2006 Data Type Numeric Representation Class Date Field Size Maximum 8 Representational Layout Yyyymmdd Domain Values A valid date (today’s or past only) Guide for Use/Examples As recorded on the birth certificate or other official documents. For

practical use as known within the hospital records.

FirstName Name First Name Synonymous Name Name Definition The first name or full name of the patient Source Standard AS 4590-2006, BloodNet Data Type Alphanumeric Representation Class Text Field Size Maximum 130 Representational Layout X(130) Domain Values Any combination of letters, numbers and special characters. Guide for Use/Examples When a patients first name or first name and second name is known then

this field should have the persons first name in it. If the persons last name is not known. If a set of names is known but it is not clear which names are known or which name is which – for instance the names have been combined into a single string then these should be put in this field in combined format

IHI Name IHI Synonymous Name Individual Health Identifier Definition The patients Individual Healthcare Identifier Source Standard NEHTA Data Type Numeric Representation Class Identifier Field Size Maximum Representational Layout N(16) Domain Values Guide for Use/Examples

LastName Name LastName



Synonymous Name Definition The patients last name. Source Standard AS 4590-2006 Data Type Alphanumeric Representation Class Text Field Size Maximum 40 Representational Layout X(40) Domain Values Any combination of letters, numbers, and special characters. Guide for Use/Examples The patients last name if specifically known. If the patients last name is

available but not specifically known (i.e. it is combined with other names) then the last name should not be used – see FirstName

RhBloodGroupPhenotype Name RhBloodGroupPhenotype Synonymous Name Rhesus Factor, Rh, RhPhenotype Definition Flag indicating whether the unit is RhD positive or RhD negative. Source Standard SNOMED CT Data Type Numeric Representation Class Code Field Size Maximum Representational Layout Domain Values Code Desciption

1 RhD Positive 0 RhD Negative


SexCode Name SexCode Synonymous Name Gender, Sex Definition A code indicating the biological distinction between male and female as

reported by a person or as determined by an interviewer. Source Standard AS4590-2006.

Also see: ABS 1285.0, ABS Statistical Standards for Social, Labour and Demographic Variables And to a lesser extent: ISO/IEC 5218; ISO/IEC 7501-1; NHDD

Data Type Numeric Representation Class Code Field Size Maximum 1 Representational Layout N(1) Domain Values See SexCode enumeration. Values will be 1,2,3 and 0. Guide for Use/Examples Should be the gender for the patient except for unborn children which

are unknown.

URNumber Name URNumber Synonymous Name MRN, Medical Record Number, URN, SRN, THCI



Definition An AHP generated unique reference number to identify the patient. Source Standard BloodNet Data Type Alphanumeric Representation Class Text Field Size Maximum 30 Representational Layout X(30) Domain Values Any combination of letters, numbers, and symbols Guide for Use/Examples As the format for the URN number or MRN of a patient is controlled by

the system the patient is registered in this field is left open.

ReceiptedIssueNoteLine Receipted issue notes lines may exist for a receipted issue note.

ABOGroupPhenotype

Name ABOGroupPhenotype Synonymous Name ABO Blood Group, Blood Group, ABO Definition The ABO Blood Group Source Standard SNOMED-CT Data Type Numeric Representation Class Code Field Size Maximum Representational Layout Domain Values See the ABOGroupPhenotype enumeration Guide for Use/Examples

AcknowledgedReceivedQuantity Name AcknowledgedReceivedQuantity Synonymous Name Acknowledged Quantity Definition The number of units that have been acknowledged. Source Standard BloodNet Data Type Numeric Representation Class Integer Field Size Maximum 4 Bytes Representational Layout N Domain Values Integers greater than or equal to zero. Guide for Use/Examples The amount of units that match this Issue Note and Issue Note Line that

have already been acknowledged. See UnacknowledgedReceivedQuantity for an explanation of how this can be used.

ComponentID Name Component ID Synonymous Name Definition The BlooodNet Component ID for this unit if it is a Component Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum



Representational Layout Domain Values One of the Component ID values returned from the

GetSupplierComponents method Guide for Use/Examples

DefectReason Name DefectReason Synonymous Name Definition The Defect ID chosen by the user receipting the item into BloodNet Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum Representational Layout N Domain Values One of the Defect Reason ID values returned by the Get Defect Reasons

method. Guide for Use/Examples

DerivedLotNumber Name DerivedLotNumber Synonymous Name Formatted Lot Number, Derived Batch Number, Parsed Lot Number. Definition The Lot or Batch Number as extracted from the Lot Number provided by

the supplier in the Issue Note LotNumber field. Source Standard BloodNet Data Type Alphanumeric Representation Class Text Field Size Maximum 20 Representational Layout X(20) Domain Values Any combination of letters, numbers, and symbols Guide for Use/Examples

DerivedLotNumberParseError Name DerivedLotNumberParseError Synonymous Name Definition A flag indicating whether the parsing algorithms implemented by

BloodNet successfully identified the Lot Number. Source Standard BloodNet Data Type Numeric Representation Class Boolean Field Size Maximum 1 bit Representational Layout X Domain Values Code Description

1 True 0 False


HasDefect Name HasDefect



Synonymous Name HasFeedback Definition Indicator of whether the unit has any feedback attached. This can

indicate there was an actual defect in the unit or there was some other inconsistency with the received unit such as it was not ordered.

Source Standard BloodNet Data Type Numeric Representation Class Boolean Field Size Maximum 1 Representational Layout Domain Values 1 indicating a defect or 0 indicating there was no defect. Guide for Use/Examples

IssueNoteLineID Name IssueNoteLineID Synonymous Name Definition The identifier assigned to the Issue Note Line item in BloodNet Source Standard BloodNet Data Type Numeric Representation Class Identifier Field Size Maximum 4 Bytes Representational Layout N Domain Values Integers above zero Guide for Use/Examples

IssuedQuantity Name IssuedQuantity Synonymous Name Definition The number of items that are indicated to have been received for this

Issue Note Line Source Standard Blood Service Data Type Numeric Representation Class Integer Field Size Maximum 4 Bytes Representational Layout N Domain Values Integers greater than zero. Guide for Use/Examples The number of items the issue note indicates the issue note line

represents.

ItemExpirationDate Name ItemExpirationDate Synonymous Name ExpiryDateTime Definition The date and time that the unit will expire according to the issue note. Source Standard NEHTA eProcurement Despatch Message, BloodService Data Type Numeric Representation Class Date and Time Field Size Maximum Representational Layout Domain Values Any date and time. Guide for Use/Examples While this field is based on the Despatch Message standard the standard



only allows for an expiry date while the information provided by the BloodService is a date and time. No conversions are performed on this data so the meaning of expiry date should be considered as the supplier’s definition.

LotNumber Name LotNumber Synonymous Name Donation Number, Batch Number, Lot Number Definition The Donation Lot Number or Batch number of the product or

component. Source Standard Blood Service Data Type Alphanumeric Representation Class Text Field Size Maximum 96 Representational Layout X(96) Domain Values A number provided by the supplier or manufacturer that identifies the

donation for components or a lot number for manufactured products. The format of this data is controlled entirely by the manufacturer. Some products lot number includes what could be considered a product code and also a lot number. In this case BloodNet does not distinguish this fact and treats the entire value as the LotNumber. This value is provided exactly as represented on the Issue Note. It may or may not contain start and stop codes, it may or may not contain encoded data, and it may or may not actually be a lot number alone. We know that there are situations in which the Blood Service provides us with incorrect information. Octagam, for example currently uses a Code 128 barcode with GS1 Application Identifiers (AI) which include both the expiry date (AI 17) and the lot number (AI 10). Some issue notes that BloodNet has received include the string of both these values and their AIs concatenated together as the Lot Number. If you are interested in the Lot Number alone use Derived Lot Number. This value is provided as presented on the IssueNote exactly as it appears. This value is not guaranteed to be unique. Frequently the value here is presented on the products outer packaging in a barcode format. In this future the Lot Number for Components could be based upon ISBT128 or some other coding scheme that works well with RFID.

Guide for Use/Examples Example: 5133347, 2865059, 5206176 (components); 3740500510, 3450700211 (products). See the section Example Product Packaging Codes for further examples.

Phenotypes Name Phenotypes Synonymous Name Definition A space delimited string containing the phenotype information provided

for the Component unit. Products have an empty value. Source Standard Blood Service Data Type Alphanumeric Representation Class X(250)



Field Size Maximum 250 Representational Layout Text Domain Values Guide for Use/Examples The phenotype string is provided by the Blood Service on units where

they have been tested. The phenotypes provided here should only be used as an indicator of the phenotypes found in the component. Further testing need to be carried out in order to confirm this. Examples: • rr D- C- E- c+ e+ Cw- K- k+ Kpa- Kpb+ Fya- Fyb+ Jka- Jkb+ M+ N- S+ s-

P1+ Lea+ Leb- Lua- Lub+ Coa+ Cob- Bga- Bgb- Wra- Vel+ Vw- Mg- Mit- Yta+ Ch+ Rg+ Ge:2,3 Dha- Kna+ Yka+ Era+ Jra+

• R1r C+ E- c+ e+ K- • rr C- E- c+ e+ K- • A1 R1R1 C+ E- c- e+ K- Fya+ Fyb+ Jka+ Jkb+ S- s+

ProductID Name ProductID Synonymous Name BloodNet Product ID Definition The BloodNet Product ID for this unit if it is a Product. Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout Domain Values One of the Product ID values returned from the GetSupplierProducts

method. Guide for Use/Examples

ProductionDate Name ProductionDate Synonymous Name CollectionDateTime, CollectedDateTime Definition The date and time that the unit was produced or collected. For fresh

components this is the collection date. Production Date is the preferred term as this is part of the NEHTA eProcurement standard.

Source Standard NEHTA eProcurement Dispatch Advice Data Type Numeric Representation Class Date and Time Field Size Maximum Representational Layout Yyyy-mm-dd hh:mm:ss.fff Domain Values A date in the past. Guide for Use/Examples The production date the production date as provided by the supplier on

the Issue note.

ReceiptedBy

Name ReceiptedBy Synonymous Name Definition The BloodNet login of the user who performed the receipting. Source Standard BloodNet Data Type Alphanumeric



Representation Class Text Field Size Maximum 100 Representational Layout X(100) Domain Values This could be any combination of alphabetic characters or a

combination of alphanumeric characters followed by a backslash and another combination of alphanumeric characters.


ReceiptedDateTime Name ReceiptedDateTime Synonymous Name Definition The UTC date and time that the Issue Note Line was receipted into

BloodNet. Source Standard BloodNet Data Type Numeric Representation Class Date and Time Field Size Maximum Representational Layout Yyyy-mm-dd hh:mm:ss.fffZ Domain Values A UTC date and time in the past Guide for Use/Examples

ReceiptedSequence Name ReceiptedSequence Synonymous Name Scan Sequence Number, Order Receipted, Order Scanned Definition A number representing the order that the item was Receipted in Source Standard BloodNet Data Type Numeric Representation Class Integer Field Size Maximum 4 Bytes Representational Layout N Domain Values A number greater than 1. The number will be unique within each Issue

Note – even over many receipting sessions. Guide for Use/Examples The Receipted Sequence is used to ensure the order that the items is

receipted in is replicated in the LIS. Items should be unpacked and receipted into BloodNet and stored in such a way as the original receipting sequence is maintained. Once receipting is complete and group labels are printed they can be attached to the correct unit based on the physical order and the Receipted Sequence.





Guide for Use/Examples Mandatory Y

SupplierItemCode Name SupplierItemCode Synonymous Name Component Code, Product Code, Blood Service Component Code Definition The Component or Product code provided by the Supplier Source Standard Blood Service Data Type Alphanumeric Representation Class Identifier Field Size Maximum 50 Representational Layout X Domain Values A unique identifier for the Product or Component as supplied by the

supplier. Presently this value will is provided by the Blood Service but will contain Product or Component Codes from other suppliers in the future. The uniqueness of this value must be ensured by the supplier and will only be unique within the supplier i.e. other suppliers may generate the same value. It is highly likely that this value will not be a GTIN.

Guide for Use/Examples Example: 04390

SupplierItemName Name SupplierItemName Synonymous Name Component Name, Product Name, Blood Service Component Name Definition The full name of the Component or Product provided by the Supplier. Source Standard Blood Service Data Type Alphanumeric Representation Class Text Field Size Maximum 100 Representational Layout X(100) Domain Values A component or product name. Guide for Use/Examples Example: RED CELLS IN SAG-M LEUCODEPLETED, BENEFIX FACTOR IX

1000 IU

UnacknowledgedReceivedQuantity Name ReceivedQuantity Synonymous Name Receipted Quantity Definition The number of units currently receipted that are yet to be

acknowledged. Source Standard BloodNet Data Type Numeric Representation Class Integer Field Size Maximum 4 Bytes Representational Layout N Domain Values Integers greater than zero. Guide for Use/Examples When receipting over more than one session, particularly for products

or anything that does not exist as a single Issue Note Line, this value



represents the number of items receipted that have not been acknowledged. This value needs to be taken in consideration with AcknowledgedReceivedQuantity to determine how many items have actually been received for this Issue Note Line. If delivery was received in err and the items were put into stock the UnacknowledgedRecievedQuantity value would be the number of items to put into stock but HasDefect would be set to true. This set of units would usable units and should pass receipting in the LIS pending any other checks required.

UnitVolume Name UnitVolume Synonymous Name Definition The volume of each the unit in millilitres. Source Standard BloodNet Data Type Numeric Representation Class Integer Field Size Maximum 4 Bytes Representational Layout N Domain Values Values greater than or equal to zero. Guide for Use/Examples While the quantity contained and net volume values in several

standards are close to usable none are clear enough to be of any benefit and the additional flexibility offered by these standards does not warrant the use of them. As a result the UnitVolume is the actual or stickered volume of the product or component if it is known.

ExtendedAttribute See the Extended Attribute common data element above for detail on how this is to be used. This object can be attached to several different parents as defined in the class diagram for this message.

Modifier

ModifierID

Name ModifierID Synonymous Name Definition The BloodNet Modifier ID for a modifier attached to this Issue Note Line Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout N Domain Values One of the Modifier ID values returned from the GetAvailableModifiers

method Guide for Use/Examples If a modifier was identified on an Issue Note Line that is a component

each of the modifiers will be indicated via a related Modifier object.



RFID The RFID entity is not mandatory and there cannot be any more than one of them for the Issue Note Line they represent.

MB01

Name MB01 Synonymous Name Memory Bank 01, EPC MB01 Definition The contents of Memory Bank 01 of a RFID Tag or equivalent. Source Standard ISO/IEC 18000-6 Data Type Binary Representation Class Field Size Maximum 128 bits Representational Layout Domain Values Guide for Use/Examples The data contained in this field is dump of all information stored in one

of the Memory Banks of the RFID tag. Assuming the implementation we decide upon is based on the ISO/IEC 18000-6 standard this will be MB01 or the Unique Unit Identification number. The field size is 128 bits to correspond to the full MB01 size rather than the size provided by the Memory Bank for the UII (96 bits)

MB11 Name MB11 Synonymous Name Memory Bank 11, EPC MB11 Definition The content of Memory Bank 11 of a RFID Tag or equivalent. Source Standard ISO/IEC 18000-6 Data Type Binary Representation Class Field Size Maximum 4096 bits Representational Layout Domain Values Guide for Use/Examples The data contained in this field is dump of all information stored in one

of the Memory Banks of the RFID tag. Assuming the implementation we decide upon is based on the ISO/IEC 18000-6 standard this will be MB11 or the user data Memory Bank. The field size of 4096 bits is not guaranteed to fit all the data we require however as the data in MB11 must conform to the list of Data Identifiers and Application Identifiers in ANSI MH10.8.2 there is probably limited use for this for large data applications. The primary use for this will be storing values current stored in barcodes. Any information stored in this field that matches a field on the Issue Note Line or Issue Note will be extracted from this data and stored on the appropriate field on the Issue Note or Issue Note Line.

MiscellaneousData Name MiscellaneousData Synonymous Name Definition The content from an RFID tag that does not fit into MB01 or MB11. Source Standard BloodNet



Data Type Binary Representation Class Field Size Maximum 32768 bits Representational Layout Domain Values Guide for Use/Examples This field will contain any data from an RFID tag that does not fit into

MB01 and MB11 for example data from a temperature logger.

UnitIdentificationNumber Name UnitIdentificationNumber Synonymous Name UUID Definition A semi unique number of the unit of component or product as

contained in the RFID tag or other permanently attached unique code. Source Standard BloodNet Data Type Binary Representation Class Identifier Field Size Maximum 96 bits Representational Layout Domain Values Guide for Use/Examples This may be in the form of an EPC SGTIN-96, ISBT-128 Donation

Identification Number or some other format - a standard has not been agreed upon. The goal will be that whatever standard is agreed upon provides a unique unit code here and that code fits within the allocated memory. It is understood that if the ISBT-128 Donation Identification Number is stored here then the unit will not be unique. This value may be a duplicate of the MB01 data



Issue Note examples Following are some example Issue Notes from suppliers marked to indicate how the data is presented in the response.



5.5 Acknowledge Receipted Issue Notes AcknowledgeReceiptedIssueNotesResponse AcknowledgeReceiptedIssueNotes(AcknowledgeReceiptedIssueNotesRequest)

Request Contract

AcknowledgeReceiptedIssueNoteRequest IssueNoteLineAcknowledgement

Root contract

Contract

Root contract

Contract

LEGEND

1 *

AcknowledgeReceiptedIssueNotesRequest This contract contains no attributes.

Issue Note Line Acknowledgement

Action

Name Action Synonymous Name Acknowledgement Action Definition The action that was taken for the Issue Note Line during the Receipting

process – specifically whether it was accepted or rejected. Source Standard BloodNet Data Type Numeric Representation Class Code Field Size Maximum Representational Layout Domain Values See the AcknowledgementAction enumeration. Guide for Use/Examples Mandatory Y

ActionReason Name ActionReason Synonymous Name Acknowledgement Action Reason Definition The reason the action chosen was taken during the Receipting process. Source Standard BloodNet Data Type Numeric Representation Class Code Field Size Maximum Representational Layout Domain Values See the AcknowledgementActionReason enumeration. Guide for Use/Examples This is the reason the Issue Note was rejected or accepted. If the issue

note was accepted while a rejection reason was chosen then the action reason used will be the default acceptance reason and vice versa.

Mandatory Y



ClientTransferEventNumber Name ClientTransferEventNumber Synonymous Name Definition A LIS supplied number relating to a particular Issue Note transfer event

that can be used to assist in marking a set of Issue Note related data back to unacknowledged.

Source Standard BloodNet Data Type Alphanumeric Representation Class Identity Field Size Maximum 30 Representational Layout X(30) Domain Values Any combination of letters, numbers, and symbols. Guide for Use/Examples A LIS should provide a unique / semi unique value back to BloodNet

here to assist in identification of the items in a transfer event or receipting action. This value can be searched for within BloodNet to identify items to be unacknowledged so they can then be sent back to the LIS. It is up to the implementation on the LIS side to determine whether all items in a single receipting event get the same event number or each line is to be treated individually.

Mandatory N

FacilityUnitUniqueIdentifier Name FacilityUnitUniqueIdentifer Synonymous Name Definition The unique unit identifier attached to a unit by the Facility. Source Standard BloodNet Data Type Alphanumeric Representation Class Identifier Field Size Maximum 30 Representational Layout X(30) Domain Values Any value chosen by a Facility or LIS to uniquely identify a unit of

component or product. It is the LIS’s responsibility to ensure the value is unique for the Facility.

Guide for Use/Examples For any Facilities that have put in place procedures to more accurately track an individual Component or Product unit BloodNet can leverage this value for more accurate data keeping. The value provided here would be used for tracking the item in later unit fate calls.

Mandatory N

IssueNoteLineID Name IssueNoteLineID Synonymous Name Consignment Note ID Definition The Identifier of the issue note line to be acknowledged. Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout N Domain Values An Issue Note Line ID value returned from the GetReceiptedIssueNotes



method. Guide for Use/Examples As lines are accepted or rejected during receipting the results should be

sent back to BloodNet. All Issue Note Line ID’s from the same issue note do not have to be sent back at the same time, and Issue Note Lines from several issue notes can be sent back together. This also does not have to happen as each Issue Note Line is processed during receipting however in order to reduce the number of Issue Note Lines that are sent down twice this process should be performed as soon as possible after receipt.

Mandatory Y

Quantity Name Quantity Synonymous Name Definition The quantity of items that was accepted or rejected into the LIS. Source Standard BloodNet Data Type Numeric Representation Class Integer Field Size Maximum 4 Bytes Representational Layout N Domain Values Any value greater than zero and less than the total number of receipted

items on the issue note. Guide for Use/Examples For items that are not uniquely identified this allows a number of the

items represented by an individual line to be acknowledged. For items that are uniquely identified this should always be one. If a number greater than the number of receipted items is received the number of items acknowledged will be the number of receipted items.

Mandatory Y

Response Contract

AcknowledgeReceiptedIssueNotesResponse This contract contains no attributes.



5.6 Fate of Unit FateOfUnitResponse FateOfUnit(FateOfUnitRequest fateOfUnitRequest) Fate of unit is provided by one of two calls. For individual unit state changes fate can be provided with the unit as the central object otherwise an episode can be created for the key status changes with the units attached.

Request Contract

ExtendedAttribute

EpisodeTransfer

AllocatedPatient

EpisodeTransfusion

ExtendedAttribute

ExtendedAttributeUnitFate

FateOfUnitRequest

ExtendedAttribute

DiscardEpisode

ExtendedAttribute

Root contract

Contract

Root contract

Contract

LEGEND

1*

1 *

1*

1

*

1

*

1

1..* 1

1

1

1 1

0..1

1 0..1

1

1

10..1

FateOfUnitRequest This contract contains no attributes.


Key

Name Key Synonymous Name Definition The name of the extended attribute



Source Standard Data Type Representation Class Field Size Maximum Representational Layout Domain Values Guide for Use/Examples See the Extended Attribute Common Data Structure Mandatory N

Value Name Value Synonymous Name Definition The value of the extended attribute Source Standard Data Type Representation Class Field Size Maximum Representational Layout Domain Values Guide for Use/Examples See the Extended Attribute Common Data Structure Mandatory N – May be an empty string.

EpisodeTransfer If the state change of a unit is a transfer the unit should include information about a transfer episode.

DestinationCustomLocationID

Name DestinationCustomLocationID Synonymous Name Definition The identifier of the transfer location the unit is being transferred to

that is not managed by BloodNet. Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout Domain Values One of the Custom Location ID values returned from the

GetCustomTransferLocations method. Guide for Use/Examples Facilities, Distribution Sites, component or product users, and suppliers

that are not managed by BloodNet are considered Custom Locations. Each facility has a list of custom transfer locations which is available from the GetCustomTransferLocations. The values returned by that method provide a way to refer to saved custom locations. If a DestinationCustomLocationID is provided the DestinationCustomLocationName is not requried – the DestinationCustomLocationID takes precedence over the DestinationCustomLocationName.

Mandatory N – One of DestinationCustomLocationName, DestinationCustomLocationID, DestinationDistributionSiteID, or



DestinationFacilityID must be provided.

DestinationCustomLocationName Name DestinationCustomLocationName Synonymous Name Definition The name of the transfer location the unit is being transferred to that is

not managed by BloodNet. Source Standard BloodNet Data Type Alphanumeric Representation Class Text Field Size Maximum 50 Representational Layout X(50) Domain Values Any combination of alphabetic characters, numbers, or symbols Guide for Use/Examples When transferring a unit to a Facility, Distribution Site, component or

product user, or supplier that is not managed by BloodNet a custom location should be used. If the Lab Systems Service pick up a custom transfer location that is already used by the Facility the existing location will be used. If a DestinationCustomLocationID is provided the DestinationCustomLocationName is not required – the DestinationCustomLocationID takes precedence over the DestinationCustomLocationName. Example: Royal Flying Doctors Service Example: Any Facility where BloodNet is not presently implemented –the AHP code should be used.

Mandatory N – one of DestinationCustomLocationName, DestinationCustomLocationID, DestinationDistributionSiteID, or DestinationFacilityID must be provided.

DestinationDistributionSiteID Name DestinationDistributionSiteID Synonymous Name Definition The identifier of the distribution site that the unit was or is being

transferred to. Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout Domain Values One of the Distribution Site ID values returned from the

GetDistributionSites method. Guide for Use/Examples If the unit has been recalled by supplier or otherwise sent back to the

supplier the Destination Distribution Site ID should be provided. Given the rules for mandatory defined below should data be provided in multiple data elements the DestinationDistributionSite would be used before the DestinationCustomLocationID but after the DestinationFacilityID

Mandatory N – One of DestinationCustomLocaitonName, DestinationCustomLocationID, DestinationDistributionSiteID, or DestinationFacilityID must be provided.



DestinationFacilityID Name DesinationFacilityID Synonymous Name Definition The identifier of the facility that the unit was or is being transferred to. Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout Domain Values One of the Facility ID values returned from the GetFacilities method Guide for Use/Examples If the unit has been transferred to another Facility and that facility is

managed by BloodNet Destination Facility ID should be provided. Given the rules for mandatory defined below, data must be provided in multiple data elements as the DestinationFacilityID is used before the DestinationDistributionSite.

Mandatory N – One of DestinationCustomLocationName, DestinationCustomLocationID, DestinationDistributionSiteID, or DestinationFacilityID must be provided.

TransferReasonID Name TransferReasonID Synonymous Name Definition The identifier reason the transfer occurred Source Standard BloodNet Data Type Numeric Representation Class Code Field Size Maximum 4 bytes Representational Layout Domain Values The Transfer Reason ID values returned from the GetTransferReasons

method. Guide for Use/Examples Used to determine the status and description of the TransferReason and

represented numerically for Blood Components or Products that are ‘Close to Expiry’.

Mandatory Y


UnitFate Unit fate expresses key information about the unit and any required information for all status changes – generalised where required. For example the EpisodeDateTime provides the information that DiscardDateTime, TransferDateTime, and TransfuseDateTime do in the batch operations.



Comments

Name Comments Synonymous Name Definition Comments related to the fate of the unit. Source Standard BloodNet Data Type Alphanumeric Representation Class Text Field Size Maximum 1000 Representational Layout X(1000) Domain Values Any combination of letters, numbers, and symbols. Guide for Use/Examples This field can be used to provide additional information relating to the

fate of the unit that cannot be captured via the other fate related fields. The information here cannot be reported upon directly. Patient details or other confidential information should not be used in this field. Example: “Only one unit of several to be transfused was out of temperature for an extended period”.

Mandatory Y

ComponentID Name Component ID Synonymous Name Definition The BlooodNet Component ID for this unit if it is a Component Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout Domain Values One of the Component ID values returned from the

GetSupplierComponents method Guide for Use/Examples Mandatory Only if ComponentID is a Component noting that either a ComponentID

or ProductID must be provided but both cannot.

EndStatus Name EndStatus Synonymous Name Definition The Final Fate of the unit. Source Standard BloodNet Data Type Numeric Representation Class Code Field Size Maximum Representational Layout Domain Values See the UnitFate enumeration. Guide for Use/Examples If an end status of a unit has been met then this value should be set. If

the status change is not related to an end status of a unit the value should be left blank.

Mandatory Y



EpisodeComments Name EpisodeComments Synonymous Name Definition Comments related to the episode as a whole as distinct from the Unit

Comments. Source Standard BloodNet Data Type Alphanumeric Representation Class Text Field Size Maximum 1000 Representational Layout X(1000) Domain Values Any combination of letters, numbers, and symbols. Guide for Use/Examples This field can be used to provide additional information relating to the

discard episode that cannot be captured via the other fate related fields. The information here cannot be reported upon directly. Patient details or other confidential information should not be used in this field. Example: “Discards for items from planned operation”

Mandatory N

EpisodeDateTime Name EpisodeDateTime Synonymous Name Definition The date and time that the units fate was changed. Source Standard BloodNet Data Type Numeric Representation Class Date and Time Field Size Maximum Representational Layout Yyyy-mm-dd hh:mm:ss.fffZ Domain Values A UTC date and time in the past or near future. Guide for Use/Examples The EpisodeDateTime is distinct from the time the event was entered

into the LIS. For example if a unit was discarded in the ward but not entered into the LIS as discarded until several days later the date that should be used would be as close as possible to the date it was actually discarded. The near future clause is included for episodes where the event is recorded before the fact. For example if a facility was transferring units a user could create a Transfer Episode in the LIS, wait a short time for it to be published to BloodNet, find the transfer episode in BloodNet, and print out the episode receipt as a packing slip / dispatch advice.

Mandatory Y

FacilityID Name FacilityID Synonymous Name BloodNetFacilityID, HospitalID Definition The Unique Identifier within the BloodNet system for the Facility

specifically a number representing a facility defined within BloodNet. Source Standard BloodNet Data Type Numeric Representation Class Foreign Key



Field Size Maximum 4 Bytes Representational Layout N Domain Values One of the FacilityID values returned from the GetManagedFacilities

method Guide for Use/Examples Mandatory Y

FacilityUnitUniqueIdentifier Name FacilityUnitUniqueIdentifer Synonymous Name Definition The unique unit identifier attached to a unit by the Facility. Source Standard BloodNet Data Type Alphanumeric Representation Class Identifier Field Size Maximum 30 Representational Layout X(30) Domain Values Any value chosen by a Facility or LIS to uniquely identify a unit of


Guide for Use/Examples For any Facilities that have put in place procedures to more accurately track an individual Component or Product unit BloodNet can leverage this value for more accurate data keeping.

Mandatory N

LotNumber Name LotNumber Synonymous Name Batch Number, Donation Number. Definition The donation number or batch number depending on the type of unit

with start and stop codes removed. Products use a Batch Number and Components us a Donation Number.

Source Standard BloodNet Data Type Alphanumeric Representation Class Text Field Size Maximum 96 Representational Layout X(96) Domain Values Guide for Use/Examples The lot number needs to be returned when providing unit fate in order

to identify the unit being fated. See the section Handling of Product Codes and Lot Numbers in the Overview for more information on how this is used.

Mandatory Y

ProductID Name ProductID Synonymous Name BloodNet Product ID Definition The BloodNet Product ID for this unit if it is a Product. Source Standard BloodNet Data Type Numeric



Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout Domain Values One of the Product ID values returned from the GetSupplierProducts

method. Guide for Use/Examples Mandatory Only if the ProductID is a Product noting that either a ProductID or

ComponentID must be provided but both cannot.

ProductType Name ProductType Synonymous Name BloodNet Product Type Definition The BloodNet Product Type for this unit Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout Domain Values One of the Product ID values returned from the GetSupplierProducts

method. Guide for Use/Examples Mandatory Only if it is a ProductID is a Product.

Quantity Name Quantity Synonymous Name Definition The number of units that this unit fate represents. Source Standard BloodNet Data Type Numeric Representation Class Integer Field Size Maximum 4 Bytes Representational Layout Domain Values Integers above 0. Guide for Use/Examples If the unit is individually tracked then the quantity will always be one.

For units that are not individually tracked then the quantity can be above one.

Mandatory Y

Status Name Status Synonymous Name Definition The current status of the unit. Source Standard BloodNet Data Type Alphanumeric Representation Class Code Field Size Maximum 50 Representational Layout X(50) Domain Values Any combination of alphabetic characters, numbers, or symbols. Ideally



it would be a value registered for the LIS via the UpdateValidFateOfUnitStatuses.

Guide for Use/Examples Example: Assumed Transfused, Confirmed Transfused Mandatory N

AllocatedPatient While a unit is allocated to a patient, or when a unit is de-allocated from a patient, information about that patient can be returned along with unit state changes. When a unit is no longer assigned to a patient and this is not changing in this episode patient information should not be provided. A patient is not mandatory and only one patient can be attached to a unit. Patient information is used for improving the quality of tracking non unique items such as Products.

ABOGroupPhenotype

Name ABOGroupPhenotype Synonymous Name ABO Blood Group, Blood Group, ABO Definition The ABO Blood Group Source Standard SNOMED-CT Data Type Numeric Representation Class Code Field Size Maximum Representational Layout Domain Values See the ABOGroupPhenotype enumeration Guide for Use/Examples Mandatory Y

APTT Name APTT Synonymous Name Activated Partial Thromboplastin Time

Definition The result of an Activated Partial Thromboplastin Time test in seconds.

The APTT test is a measure of coagulation. Source Standard SNOMED-CT Data Type Numeric Representation Class Integer Field Size Maximum 999 – maximum value Representational Layout N Domain Values A number above 0 or null if there is no valid data Guide for Use/Examples Example: 35. Mandatory N

BirthDate Name BirthDate Synonymous Name DOB, Date of Birth Definition The date that the patient was born Source Standard AS 4590-2006 Data Type Numeric Representation Class Date



Field Size Maximum 8 Representational Layout Yyyymmdd Domain Values A valid date (today’s or past only) Guide for Use/Examples As recorded on the birth certificate or other official documents. For

practical use as known within the hospital records. Mandatory Y

DateOfAPTTTest Name DateOfAPTTTest Synonymous Name Definition The date that the APTT test for which results are stored was carried out Source Standard BloodNet Data Type Numeric Representation Class Date and Time Field Size Maximum Representational Layout Yyyy-mm-dd hh:mm:ss.fffZ Domain Values Any date in the past Guide for Use/Examples If there is no valid APTT data then the field should be blank. If there is

APTT data the field should not be blank. Mandatory Only if APTT is provided

DateOfFibrinogenTest Name DateOfFibrinogenTest Synonymous Name Definition The date that the Fibrinogen test for which the results are stored was

carried out. Source Standard Data Type Numeric Representation Class Date and Time Field Size Maximum Representational Layout Yyyy-mm-dd hh:mm:ss.fffZ Domain Values Any date in the past Guide for Use/Examples Mandatory Only if Fibrinogen is provided

DateOfHaemoglobinTest Name DateOfHaemoglobinTest Synonymous Name Definition The date that the Haemoglobin test for which the results are stored was

carried out Source Standard Data Type Numeric Representation Class Date and Time Field Size Maximum Representational Layout Yyyy-mm-dd hh:mm:ss.fffZ Domain Values Any date in the past in UTC time Guide for Use/Examples Mandatory Only if Haemoglobin is provided



DateOfINRTest Name DateOfINRTest Synonymous Name Definition The date that the APTT test for which results are stored was carried out. Source Standard Data Type Numeric Representation Class Date and Time Field Size Maximum Representational Layout Yyyy-mm-dd hh:mm:ss.fffZ Domain Values Any date in the past Guide for Use/Examples Mandatory Only if INR is provided

DateOfPlateletCountTest Name DateOfPlateletCountTest Synonymous Name Definition The date that the Platelet Count test for which the results are stored

was carried out Source Standard Data Type Numeric Representation Class Date and Time Field Size Maximum Representational Layout Yyyy-mm-dd hh:mm:ss.fffZ Domain Values Any date in the past in UTC time Guide for Use/Examples Mandatory Only if Platelet Count is provided

Fibrinogen Name Fibrinogen Synonymous Name Definition The results of a Fibrinogen test in grams per litre. The result is a

measure of coagulation. Source Standard Data Type Numeric Representation Class Decimal Field Size Maximum 99.9 – maximum value Representational Layout N.N Domain Values Generally a number between 0 and 9. Guide for Use/Examples A value up to 99.9 is supported though it should not be required.

Example: 2.8 Mandatory N

Haemoglobin Name Haemoglobin Synonymous Name Definition The results of a Haemoglobin test in g/L Source Standard SNOMED-CT Data Type Numeric



Representation Class Integer Field Size Maximum 3 Representational Layout NNN Domain Values Positive integers Guide for Use/Examples Example: 70 Mandatory N

IHI Name IHI Synonymous Name Individual Health Identifier Definition The patients Individual Healthcare Identifier Source Standard NEHTA Data Type Numeric Representation Class Identifier Field Size Maximum Representational Layout N(16) Domain Values Guide for Use/Examples Mandatory N

INR Name INR Synonymous Name International Normalised Ratio Definition The result of an International Normalised Ratio calculation. The INR is a

measure of coagulation. Source Standard SNOMED-CT Data Type Numeric Representation Class Decimal Field Size Maximum 99.9 – maximum value Representational Layout NN.N Domain Values A number between 0 and 99 to one decimal place Guide for Use/Examples Example 1.2 Mandatory N

PlateletCount Name PlateletCount Synonymous Name Definition The result of a test for platelets x10e9/L. Source Standard SNOMED-CT Data Type Numeric Representation Class Integer Field Size Maximum 3 Representational Layout NNN Domain Values Positive integers above 0 Guide for Use/Examples E.g.: 250 Mandatory N









Data Type Numeric Representation Class Code Field Size Maximum 1 Representational Layout N(1) Domain Values See SexCode enumeration. Values will be 0, 1, 2, and 3. Guide for Use/Examples Should be the gender for the patient except for unborn children which

are unknown. Mandatory Y

URNumber Name URNumber Synonymous Name MRN, Medical Record Number, SRN, URN, THCI Definition An AHP generated unique reference number to identify the patient. Source Standard BloodNet Data Type Alphanumeric Representation Class Text Field Size Maximum 30 Representational Layout X(30) Domain Values Any combination of letters, numbers, and symbols Guide for Use/Examples As the format for the URNumber or MRN of a patient is controlled by

the system the patient is registered in this field is left fairly open.



Mandatory Y


EpisodeTransfusion If the state change of an episode is a transfusion the unit should include information about a transfusion.

Comments

Name Comments Synonymous Name Definition Comments relating to a transfusion episode Source Standard BloodNet Data Type Alphanumeric Representation Class Text Field Size Maximum 500 Representational Layout X(500) Domain Values Any combination of letters, numbers and symbols. Guide for Use/Examples The information here can be used to provide additional information

relating to the transfusion of the unit that cannot be captured via the other transfusion related fields. The information here cannot be reported upon directly. Patient details or other confidential information should not be used in this field.

Mandatory N

DRG Name DRG Synonymous Name Diagnosis Related Group Definition The Australian Refined Diagnosis Related Group information for the

patient as presently known. Source Standard Department of Health and Ageing AR-DRGs Data Type Alphanumeric Representation Class Code Field Size Maximum 4 Representational Layout X(4) Domain Values An AR-DRG code relevant for the reporting period of the episode Guide for Use/Examples Example: I03B

If a patient has a DRG associated with their case at present then the primary DRG can be included in this field.

Mandatory N

DRGDescription Name DRGDescription Synonymous Name Diagnosis Related Group Description Definition Any textual description included with diagnosis related group



information provided. Source Standard Department of Health and Ageing AR-DRGs Data Type Alphanumeric Representation Class Text Field Size Maximum Representational Layout Domain Values Any combination of letters, numbers and special characters. Guide for Use/Examples Mandatory N

RegistrarFirstName Name RegistrarFirstName Synonymous Name Definition The First Name of the person who ordered the transfusion. Source Standard BloodNet Data Type Alphabetic Representation Class Text Field Size Maximum 50 Representational Layout A(50) Domain Values Any combination of letters. Guide for Use/Examples Mandatory N

RegistrarIHI Name IHI Synonymous Name Registrar Individual Health Identifier Definition The IHI of the person who ordered the transfusion. Source Standard NEHTA Data Type Numeric Representation Class Identifier Field Size Maximum Representational Layout N(16) Domain Values Guide for Use/Examples Mandatory N

RegistrarLastName Name RegistrarLastName Synonymous Name Definition The Last Name of the person who ordered the transfusion. Source Standard BloodNet Data Type Alphabetic Representation Class Text Field Size Maximum 50 Representational Layout A(50) Domain Values Any combination of letters. Guide for Use/Examples Mandatory N



RegistrarSpeciality Name RegistrarSpeciality Synonymous Name Definition The Speciality of the person who ordered the transfusion. Source Standard BloodNet Data Type Alphanumeric Representation Class Text Field Size Maximum 150 Representational Layout X(150) Domain Values Any combination of letters, numbers, and symbols. Guide for Use/Examples Mandatory N

TransfusionDateTime Name TransfusionDateTime Synonymous Name Definition The Date and Time that the transfusion took place. Source Standard BloodNet Data Type Numeric Representation Class Date and Time Field Size Maximum Representational Layout Yyyy-mm-dd hh:mm:ss.fffZ Domain Values A UTC date and time in the past Guide for Use/Examples Mandatory Y

TransfusionLocation Name TransfusionLocation Name Definition The location within the hospital premises that the transfusion occurred. Source Standard SNOMED CT Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout N Domain Values One of the Transfusion Location ID values returned from the

GetTransfusionLocations method Guide for Use/Examples If the general location where the transfusion occurred is known the

closest possible match should be used. Mandatory N

DiscardEpisode If the state change of a unit is a discard the unit should include information about a Discard Episode.

DiscardLocation

Name DiscardLocation Synonymous Name Definition The location that the discard was performed at.



Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum Representational Layout N Domain Values One of DiscardLocationID values from the GetDiscardLocations method. Guide for Use/Examples Mandatory Y

DiscardReason Name DiscardReason Synonymous Name Definition The reason that the discard was performed based on a list of discard

reasons defined by the BloodNet User Group. Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum Representational Layout N Domain Values One of the DiscardReasonID values from the GetDiscardReasons

method. Guide for Use/Examples Mandatory Y


Response Contract

FateOfUnitResponse This contract contains no attributes.



5.7 Fate Of Unit Episode FateOfUnitEpisodeResponse FateOfUnitEpisode(FateOfUnitEpisodeRequest)

Request Contract

EpisodeTransfer

AllocatedPatient

EpisodeTransfusion

ExtendedAttributeUnitFateExtendedAttribute

DiscardEpisode

FateOfUnitEpisodeRequest

ExtendedAttribute

EpisodeStateChange

Root contract

Contract

Root contract

Contract

LEGEND

1*

1*

1 *

1..*

1

1..*

1

1

0..1

1 0..1

1

0..1

1

0..1

1

0..1

1

1..*

1 0..1

1

0..1

1

0..1

0..11

Extended Attribute See the Extended Attribute common data element for detail on how this is to be used. This object can be attached to several different parents as defined in the class diagram for this message.

Key

Name Key Synonymous Name Definition The name of the extended attribute Source Standard Data Type Representation Class Field Size Maximum Representational Layout Domain Values Guide for Use/Examples See the Extended Attribute Common Data Structure Mandatory N




FateOfUnitEpisodeRequest

FacilityID

Name FacilityID Synonymous Name BloodNetFacilityID, HospitalID Definition The Unique Identifier within the BloodNet system for the Facility




it would be a value registered for the LIS via the UpdateValidFateOfUnitStatuses.

Guide for Use/Examples The status can be used to record the LIS specific status change related to an end status episode, or if the episode is not related to an end status then the State Change Episode can be used to record additional detail about the state change. Example: Assumed Transfused, Confirmed Transfused

Mandatory N



EpisodeTransfer

If the state change of a unit is a transfer the unit should include information about a transfer episode.

AHPCodeTransferredTo

Name AHPCodeTransferredTo Synonymous Name Definition The AHP code that the transfer is being sent to. Source Standard BloodNet Data Type Alphanumeric Representation Class Text Field Size Maximum 200 Representational Layout X Domain Values Guide for Use/Examples The AHP code should be used. Mandatory Y

Comments Name Comments Synonymous Name Definition The AHP Transfer note comments. Source Standard BloodNet Data Type Alphanumeric Representation Class Text Field Size Maximum 200 Representational Layout X Domain Values Guide for Use/Examples Comments are used to provide information about individual lines

Transfer Episode comments. This field is frequently used by the AHPs to indicate things such as: • How it is being transported and when it is expected to arrive (for

example which train). • Specific requirements • Information to help relate this back to a record in the Facility

Mandatory Y

DestinationCustomLocationID Name DestinationCustomLocationID Synonymous Name Definition The identifier of the transfer location the unit is being transferred to

that is not managed by BloodNet. Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout Domain Values One of the Custom Location ID values returned from the



GetCustomTransferLocations method. Guide for Use/Examples Facilities, Distribution Sites, component or product users, and suppliers

that are not managed by BloodNet are considered Custom Locations. Each facility has a list of custom transfer locations which is available from the GetCustomTransferLocations. The values returned by that method provide a way to refer to saved custom locations. If a DestinationCustomLocationID is provided the DestinationCustomLocationName is not required – the DestinationCustomLocationID takes precedence over the DestinationCustomLocationName.

Mandatory N – one of DestinationCustomLocationName, DestinationCustomLocationID, DestinationDistributionSiteID, or DestinationFacilityID must be provided.

DestinationCustomLocationName Name DestinationCustomLocationName Synonymous Name Definition The name of the transfer location the unit is being transferred to that is

not managed by BloodNet. Source Standard BloodNet Data Type Alphanumeric Representation Class Text Field Size Maximum 50 Representational Layout X(50) Domain Values Any combination of alphabetic characters, numbers, or symbols Guide for Use/Examples When transferring a unit to a Facility, Distribution Site, component or

product user, or supplier that is not managed by BloodNet a custom location should be used. If the Lab Systems Service pick up a custom transfer location that is already used by the Facility the existing location will be used. If a DestinationCustomLocationID is provided the DestinationCustomLocationName is not required – the DestinationCustomLocationID takes precedence over the DestinationCustomLocationName. Example: Royal Flying Doctors Service Example: Any Facility where BloodNet is not presently implemented –the AHP code should be used.

Mandatory N – one of DestinationCustomLocaitonName, DestinationCustomLocationID, DestinationDistributionSiteID, or DestinationFacilityID must be provided.

DestinationDistributionSiteID Name DestinationDistributionSiteID Synonymous Name Definition The identifier of the distribution site that the unit was transferred to. Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout



Domain Values One of the Distribution Site ID values returned from the GetDistributionSites method.

Guide for Use/Examples If the unit has been recalled by supplier or otherwise sent back to the supplier the Destination Distribution Site ID should be provided. Given the rules for mandatory defined below should data be provided in multiple data elements the DestinationDistributionSite would be used before the DestinationCustomLocationID but after the DestinationFacilityID


DestinationFacilityID Name DesinationFacilityID Synonymous Name Definition The identifier of the facility that the unit was transferred to. Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout Domain Values One of the Facility ID values returned from the GetFacilities method Guide for Use/Examples If the unit has been transferred to another Facility and that facility is

managed by BloodNet Destination Facility ID should be provided. Given the rules for mandatory as defined below, data must be provided in multiple data elements for the DestinationFacilityID before the DestinationDistributionSite.


TransferDateTime Name TransferDateTime Synonymous Name Definition The date and time that the transfer was performed on. Source Standard Data Type Numeric Representation Class Date and Time Field Size Maximum Representational Layout Yyyy-mm-dd hh:mm:ss.fffZ Domain Values Any UTC date time in the past or near future. Guide for Use/Examples This value represents the date and time that a unit is going to be

transferred to another facility. It is understood that is it not practical to record the date and time that a unit is picked up by a courier and consider any date value that appropriately represents the time a unit is transferred is acceptable.

Mandatory Y



TransferReasonID Name TransferReasonID Synonymous Name Definition The reason the transfer occurred Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum Representational Layout Domain Values The Transfer Reason ID values returned from the GetTransferReasons

method. Guide for Use/Examples Mandatory Y

EpisodeStateChange A state change episode can be used to create an episode the records a non-final state change

Comments



Mandatory N

StateChangeDateTime Name StateChangeDateTime Synonymous Name Definition The date and time that the state changed. Source Standard Data Type Numeric Representation Class Date and Time Field Size Maximum Representational Layout Yyyy-mm-dd hh:mm:ss.fffZ Domain Values Any UTC date time in the past or near future. Guide for Use/Examples This value represents the date and time that a unit’s status changed. Mandatory Y




UnitFate Unit fate expresses key information about the unit and any required information for all status changes – generalised where required. For example the EpisodeDateTime provides the information that DiscardDateTime, TransferDateTime, and TransfuseDateTime do in the batch operations.

Comments

Name Comments Synonymous Name Definition Comments related to the fate of the unit. Source Standard BloodNet Data Type Alphanumeric Representation Class Text Field Size Maximum 1000 Representational Layout X(1000) Domain Values Any combination of letters, numbers, and symbols Guide for Use/Examples The information here can be used to provide additional information

relating to the fate of the unit that cannot be captured via the other fate related fields. The information here cannot be reported upon directly. Patient details or other confidential information should not be used in this field.

Mandatory Y

ComponentID Name Component ID Synonymous Name Definition The BlooodNet Component ID for this unit if it is a Component Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout Domain Values One of the Component ID values returned from the

GetSupplierComponents method Guide for Use/Examples Mandatory Only if ComponentID is a Component noting that either a ComponentID

or ProductID must be provided but both cannot.

EndStatus Name EndStatus Synonymous Name Definition The Final Fate of the unit. Source Standard BloodNet



Data Type Numeric Representation Class Code Field Size Maximum Representational Layout Domain Values See the UnitFate enumeration. Guide for Use/Examples If an end status of a unit has been met then this value should be set. If

the status change is not related to an end status of a unit the value should be left blank.

Mandatory Y

EpisodeDateTime Name EpisodeDateTime Synonymous Name Definition The date and time that the units fate was changed. Source Standard BloodNet Data Type Numeric Representation Class Date and Time Field Size Maximum Representational Layout Yyyy-mm-dd hh:mm:ss.fffZ Domain Values Any UTC date time in the past or near future. Guide for Use/Examples The EpisodeDateTime is distinct from the time the event was entered

into the LIS. For example if a unit was discarded in the ward but not entered into the LIS as discarded until several days later the date that should be used would be as close as possible to the date it was actually discarded.

Mandatory Y

FacilityID Name FacilityID Synonymous Name BloodNetFacilityID, HospitalID Definition The Unique Identifier within the BloodNet system for the Facility



FacilityUnitUniqueIdentifier Name FacilityUnitUniqueIdentifer Synonymous Name Definition The unique unit identifier attached to a unit by the Facility. Source Standard BloodNet Data Type Alphanumeric



Representation Class Identifier Field Size Maximum 30 Representational Layout X(30) Domain Values Any value chosen by a Facility or LIS to uniquely identify a unit of


Guide for Use/Examples For any Facilities that have put in place procedures to more accurately track an individual Component or Product unit BloodNet can leverage this value for more accurate data keeping.

Mandatory N

LotNumber Name LotNumber Synonymous Name Batch Number, Donation Number. Definition The donation number or batch number depending on the type of unit

with start and stop codes removed. Products use a Batch Number and Components us a Donation Number.

Source Standard BloodNet Data Type Alphanumeric Representation Class Text Field Size Maximum 96 Representational Layout X(96) Domain Values Guide for Use/Examples The lot number needs to be returned when providing unit fate in order

to identify the unit being fated. See the section Handling of Product Codes and Lot Numbers in the Overview for more information on how this is used.

Mandatory Y

ProductID Name ProductID Synonymous Name BloodNet Product ID Definition The BloodNet Product ID for this unit if it is a Product. Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout Domain Values One of the Product ID values returned from the GetSupplierProducts

method. Guide for Use/Examples Mandatory Only if ProductID is a Product noting that either a ProductID or


ProductType Name ProductType Synonymous Name BloodNet Product Type Definition The BloodNet Product Type for this unit



Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout Domain Values One of the Product ID values returned from the GetSupplierProducts

method. Guide for Use/Examples Mandatory Only if the ProductID is a Product

Quantity Name Quantity Synonymous Name Definition The number of units that this unit fate represents. Source Standard BloodNet Data Type Numeric Representation Class Integer Field Size Maximum 4 Bytes Representational Layout Domain Values Integers above 0. Guide for Use/Examples If the unit is individually tracked then the quantity will always be one.

For units that are not individually tracked then the quantity can be above one.

Mandatory Y


it would be a value registered for the LIS via the UpdateValidFateOfUnitStatuses

Guide for Use/Examples Example: Assumed Transfused, Confirmed Transfused Mandatory N

AllocatedPatient While a unit is allocated to a patient, or when a unit is de-allocated from a patient, information about that patient can be returned along with unit state changes. When a unit is no longer assigned to a patient and this is not changing in this episode patient information should not be provided. A patient is not mandatory and only one patient can be attached to a unit. Patient information is used for improving the quality of tracking non unique items such as Products.



ABOGroupPhenotype

Name ABOGroupPhenotype Synonymous Name ABO Blood Group, Blood Group, ABO Definition The ABO Blood Group Source Standard SNOMED-CT Data Type Numeric Representation Class Code Field Size Maximum Representational Layout Domain Values See the ABOGroupPhenotype enumeration Guide for Use/Examples Mandatory N

APTT Name APTT Synonymous Name Activated Partial Thromboplastin Time

Definition The result of an Activated Partial Thromboplastin Time test in seconds.

The APTT test is a measure of coagulation. Source Standard SNOMED-CT Data Type Numeric Representation Class Integer Field Size Maximum 999 – maximum value Representational Layout N Domain Values A number above 0 or null if there is no valid data Guide for Use/Examples Example: 35. Mandatory N

BirthDate Name BirthDate Synonymous Name DOB, Date of Birth Definition The date that the patient was born Source Standard AS 4590-2006 Data Type Numeric Representation Class Date Field Size Maximum 8 Representational Layout Yyyymmdd Domain Values A valid date (today’s or past only) Guide for Use/Examples As recorded on the birth certificate or other official documents. For

practical use as known within the hospital records. Mandatory N

DateOfAPTTTest Name DateOfAPTTTest Synonymous Name Definition The date that the APTT test for which results are stored was carried out Source Standard BloodNet Data Type Numeric



Representation Class Date and Time Field Size Maximum Representational Layout Yyyy-mm-dd hh:mm:ss.fffZ Domain Values Any date in the past Guide for Use/Examples If there is no valid APTT data then the field should be blank. If there is

APTT data the field should not be blank. Mandatory Only if APTT is provided

DateOfFibrinogenTest Name DateOfFibrinogenTest Synonymous Name Definition The date that the Fibrinogen test for which the results are stored was

carried out. Source Standard Data Type Numeric Representation Class Date and Time Field Size Maximum Representational Layout Yyyy-mm-dd hh:mm:ss.fffZ Domain Values Any date in the past Guide for Use/Examples Mandatory Only if Fibrinogen is provided

DateOfHaemoglobinTest Name DateOfHaemoglobinTest Synonymous Name Definition The date that the Haemoglobin test for which the results are stored was

carried out Source Standard Data Type Numeric Representation Class Date and Time Field Size Maximum Representational Layout Yyyy-mm-dd hh:mm:ss.fffZ Domain Values Any date in the past in UTC time Guide for Use/Examples Mandatory Only if Haemoglobin is provided

DateOfINRTest Name DateOfINRTest Synonymous Name Definition The date that the APTT test for which results are stored was carried out. Source Standard Data Type Numeric Representation Class Date and Time Field Size Maximum Representational Layout Yyyy-mm-dd hh:mm:ss.fffZ Domain Values Any date in the past Guide for Use/Examples Mandatory Only if INR is provided



DateOfPlateletCountTest Name DateOfPlateletCountTest Synonymous Name Definition The date that the Platelet Count test for which the results are stored

was carried out Source Standard Data Type Numeric Representation Class Date and Time Field Size Maximum Representational Layout Yyyy-mm-dd hh:mm:ss.fffZ Domain Values Any date in the past in UTC time Guide for Use/Examples Mandatory Only if Platelet Count is provided

Fibrinogen Name Fibrinogen Synonymous Name Definition The results of a Fibrinogen test in grams per litre. The result is a

measure of coagulation. Source Standard Data Type Numeric Representation Class Decimal Field Size Maximum 99.9 – maximum value Representational Layout N.N Domain Values Generally a number between 0 and 9. Guide for Use/Examples A value up to 99.9 is supported though it should not be required.

Example: 2.8 Mandatory N

Haemoglobin Name Haemoglobin Synonymous Name Definition The results of a Haemoglobin test in g/L Source Standard SNOMED-CT Data Type Numeric Representation Class Integer Field Size Maximum 3 Representational Layout NNN Domain Values Positive integers Guide for Use/Examples Example: 70 Mandatory N

IHI Name IHI Synonymous Name Individual Health Identifier Definition The patients Individual Healthcare Identifier Source Standard NEHTA Data Type Numeric



Representation Class Identifier Field Size Maximum Representational Layout N(16) Domain Values Guide for Use/Examples Mandatory N

INR Name INR Synonymous Name International Normalised Ratio Definition The result of an International Normalised Ratio calculation. The INR is a

measure of coagulation. Source Standard SNOMED-CT Data Type Numeric Representation Class Decimal Field Size Maximum 99.9 – maximum value Representational Layout NN.N Domain Values A number between 0 and 99 to one decimal place Guide for Use/Examples Example 1.2 Mandatory N

PlateletCount Name PlateletCount Synonymous Name Definition The result of a test for platelets x10e9/L. Source Standard SNOMED-CT Data Type Numeric Representation Class Integer Field Size Maximum 3 Representational Layout NNN Domain Values Positive integers above 0 Guide for Use/Examples E.g.: 250 Domain Values See SexCode enumeration. Values will be 0, 1, 2, and 3. Guide for Use/Examples Should be the gender for the patient except for unborn children which



1 RhD Positive



0 RhD Negative

Guide for Use/Examples Mandatory N




Data Type Numeric Representation Class Code Field Size Maximum 1 Representational Layout N(1) Domain Values See SexCode enumeration. Values will be 0, 1, 2, and 3. Guide for Use/Examples Should be the gender for the patient except for unborn children which


URNumber Name URNumber Synonymous Name MRN, Medical Record Number, SRN, URN, THCI Definition An AHP generated unique reference number to identify the patient. Source Standard BloodNet Data Type Alphanumeric Representation Class Text Field Size Maximum 30 Representational Layout X(30) Domain Values Any combination of letters, numbers, and symbols Guide for Use/Examples As the format for the URNumber or MRN of a patient is controlled by

the system the patient is registered in this field is left fairly open. Mandatory N


EpisodeTransfusion If the state change of an episode is a transfusion the unit should include information about a transfusion.



Comments



Mandatory N

DRG Name DRG Synonymous Name Diagnosis Related Group Definition The Australian Refined Diagnosis Related Group information for the

patient as presently known. Source Standard Department of Health and Ageing AR-DRGs Data Type Alphanumeric Representation Class Code Field Size Maximum 4 Representational Layout X(4) Domain Values An AR-DRG code relevant for the reporting period of the episode Guide for Use/Examples Example: I03B

If a patient has a DRG associated with their case at present then the primary DRG can be included in this field.

Mandatory N

DRGDescription Name DRGDescription Synonymous Name Diagnosis Related Group Description Definition Any textual description included with diagnosis related group

information provided Source Standard Data Type Alphanumeric Representation Class Text Field Size Maximum Representational Layout Domain Values Any combination of letters, numbers and special characters. Guide for Use/Examples Mandatory N



RegistrarFirstName Name RegistrarFirstName Synonymous Name Definition The First Name of the person who ordered the transfusion. Source Standard BloodNet Data Type Alphabetic Representation Class Text Field Size Maximum 50 Representational Layout A(50) Domain Values Any combination of letters. Guide for Use/Examples Mandatory N

RegistrarIHI Name RegistrarIHI Synonymous Name Registrar Individual Health Identifier Definition The IHI of the person who ordered the transfusion. Source Standard NEHTA Data Type Numeric Representation Class Identifier Field Size Maximum Representational Layout N(16) Domain Values Guide for Use/Examples Mandatory N

RegistrarLastName Name RegistrarLastName Synonymous Name Definition The Last Name of the person who ordered the transfusion. Source Standard BloodNet Data Type Alphabetic Representation Class Text Field Size Maximum 50 Representational Layout A(50) Domain Values Any combination of letters. Guide for Use/Examples Mandatory N

RegistrarSpeciality Name RegistrarSpeciality Synonymous Name Definition The Speciality of the person who ordered the transfusion. Source Standard BloodNet Data Type Alphanumeric Representation Class Text Field Size Maximum 150 Representational Layout X(150)



Domain Values Any combination of letters, numbers, and symbols. Guide for Use/Examples Mandatory N

TransfusionDateTime Name TransfusionDateTime Synonymous Name Definition The Date and Time that the transfusion took place. Source Standard BloodNet Data Type Numeric Representation Class Date and Time Field Size Maximum Representational Layout Yyyy-mm-dd hh:mm:ss.fffZ Domain Values A UTC date and time in the past Guide for Use/Examples Mandatory Y

TransfusionLocation Name TransfusionLocation Synonymous Name Definition The location within the hospital premises that the transfusion occurred. Source Standard SNOMED CT Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout N Domain Values One of the Transfusion Location ID values returned from the

GetTransfusionLocations method Guide for Use/Examples If the general location where the transfusion occurred is known the

closest possible match should be used. Mandatory N

DiscardEpisode If the state change of a unit is a discard the unit should include information about a Discard Episode.

Comments

Name Comments Synonymous Name Definition Comments relating to the discard episode. Source Standard BloodNet Data Type Alphanumeric Representation Class Text Field Size Maximum 500 Representational Layout X(500) Domain Values Any combination of letters, numbers and special characters. Guide for Use/Examples This is not presently used in BloodNet. Information should be provided

for each item in a discard episode rather than the discard episode itself. Patient details or other confidential information should not be used in



this field. Mandatory N

DiscardDateTime Name DiscardDateTime Synonymous Name Definition The date and time that the discard was performed on. Source Standard BloodNet Data Type Numeric Representation Class Date and Time Field Size Maximum Representational Layout Yyyy-mm-dd hh:mm:ss.fffZ Domain Values Any date in the past in UTC format. Guide for Use/Examples This value is not related to the expiry date of the unit or the date that

the discard was entered into the system but the date the discard actually occurred. If units are discarded and recorded as discarded on paper before being put into the system the value should be the date that record was taken on paper. Failing the ability to get the date that the discard was actually performed the date that the discard is recorded into the LIS or BloodNet is appropriate.

Mandatory Y

DiscardLocation Name DiscardLocation Synonymous Name Definition The location that the discard was performed at. Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum Representational Layout N Domain Values One of DiscardLocationID values from the GetDiscardLocations method. Guide for Use/Examples Mandatory Y

DiscardReason Name DiscardReason Synonymous Name Definition The reason that the discard was performed based on a list of discard

reasons defined by the BloodNet User Group. Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum Representational Layout N Domain Values One of the DiscardReasonID values from GetDiscardReasons method. Guide for Use/Examples Mandatory Y



Response Contract

FateOfUnitEpisodeResponse This contract contains no attributes.



5.8 Update Real Time Inventory Levels UpdateRealTimeInventoryLevelsResponse UpdateRealTimeInventoryLevels(UpdateRealTimeInventoryLevelsRequest)

Unlike the name suggests Real Time Inventory Levels are not actually real time or a complete dump of the inventory. Real time inventory levels are a construct for storing a summary of a Facilities inventory historically and in near real time. Real time inventory levels perform roll up the product information to the BloodNet Product ID and the component information based on the BloodNet Component ID, ABO Blood Group, Rh Blood Group, and Modifiers.

Request Contract

ExtendedAttribute

Component

FacilityInventory

Modifier

ExtendedAttribute

UpdateRealTimeInventory LevelsRequest Product

ExtendedAttribute

*1

*1

*1

*1

*1

*

1

*1

Root contract

Contract

Root contract

Contract

LEGEND


Key

Name Key Synonymous Name Definition The name of the extended attribute Source Standard Data Type Representation Class Field Size Maximum



Representational Layout Domain Values Guide for Use/Examples See the Extended Attribute Common Data Structure Mandatory N


Component Component items exist off the facility inventory for each component type / modifier combination that the Facility has in stock or usually has in stock.

ABOGroupPhenotype

Name ABOGroupPhenotype Synonymous Name ABO Blood Group, Blood Group, ABO Definition The ABO Blood Group Source Standard SNOMED-CT Data Type Numeric Representation Class Code Field Size Maximum Representational Layout Domain Values See the ABOGroupPhenotype enumeration Guide for Use/Examples Mandatory Y

ComponentID Name Component ID Synonymous Name Definition The BlooodNet Component ID for this unit if it is a Component Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout N Domain Values One of the Component ID values returned from the

GetSupplierComponents method Guide for Use/Examples Mandatory Only if ComponentID is a Component noting that either a



ComponentID or ProductID must be provided but both cannot.

OnHand Name OnHand Synonymous Name Stock On Hand, Stock Level Definition The number of units in this stock category Source Standard BloodNet Data Type Numeric Representation Class Integer Field Size Maximum 4 Bytes Representational Layout N Domain Values Values equal to and above zero Guide for Use/Examples E.g.: 60 Mandatory Y




Modifier Zero too many modifiers can be attached to a component. Modifiers represent a specific requirement for a component that cannot (is not) represented by a different product. Modifiers are used for things such as 'Irradiated', 'CMV Negative', and 'Less than 10 Days' Components. Modifiers cannot be attached to a product. See the GetAvailableModifiersResponse for more information.

ModifierID

Name ModifierID Synonymous Name BloodNetModifierID Definition An identifier for a Modifier as available in the GetModifiers method Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout N Domain Values One of the ModifierID values returned from the GetAvailableModifiers

method.




UpdateRealTimeInventoryLevelRequest

Date

Name Date Synonymous Name Definition The date that this real time inventory request contains data for. Source Standard BloodNet Data Type Numeric Representation Class Date Field Size Maximum Representational Layout Yyyy-mm-dd hh:mm:ss.fffZ Domain Values Any date in the past. The date should not be adjusted for UTC time Guide for Use/Examples Mandatory Y

FacilityInventory

FacilityID

Name FacilityID Synonymous Name BloodNetFacilityID, HospitalID Definition The Unique Identifier within the BloodNet system for the Facility Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout N Domain Values A integer identifying a facility defined within BloodNet as returned from

the GetManagedFacilities method Guide for Use/Examples Mandatory Y

Product

OnHand

Name OnHand Synonymous Name Stock On Hand, Sock Level Definition The number of units in this stock category Source Standard BloodNet Data Type Numeric Representation Class Integer Field Size Maximum 4 Bytes Representational Layout N Domain Values Values equal to and above zero Guide for Use/Examples E.g.: 60 Mandatory Y



ProductID Name ProductID Synonymous Name Definition The BloodNet Product ID for this unit if it is a Product. Source Standard BloodNet Data Type Numeric Representation Class Foreign Key Field Size Maximum 4 Bytes Representational Layout N Domain Values One of the Product ID values returned from the GetSupplierProducts

method. Guide for Use/Examples Mandatory Only if ProductID is a Product noting that either a ProdcutID or



Response Contract

UpdateRealTimeInventoryLevelResponse This contract contains no attributes.



5.9 Enumerations

ABOGroupPhenotype Code Desciption Definition Deprecated 0 A The A Blood Group False 1 B The B Blood Group False 2 O The O Blood Group False 3 AB The AB Blood Group False

AcknowledgementAction Code Desciption Definition Deprecated 0 Accept The unit is now in the LISs inventory. False 1 Reject The unit is not in the LISs inventory False 2 Not Applicable The LIS does not support the concept of

Accepting or Rejecting a unit, or the action taken in receipting does not reflect the concept of Acceptance or Rejection of a unit

False

AcknowledgementActionReason Code Desciption Definition Deprecated 0 Unknown Item Some information presented in the Issue Note

Line failed to match a known Component or Product in the LIS

False

1 Unsupported Item The item presented was known but understood not to work correctly or not configured in the LIS for some other reason.

False

2 Unit Defected The defected unit had a defect type that resulted in a certain action. Unit Defected can be used for an Acceptance reason or a Rejection reason.

False

3 Already In Inventory The unit was entered into the LISs inventory already via a manual process or due to acknowledged being set by the user.

False

4 Failed System Checks Any checks applied automatically by the LIS resulted in the unit being rejected.

False

5 Failed User Checks Any check performed by the user resulted in the unit being rejected.

False

6 Accepted Default accepted reason. This should be used if no other match can be found.

False

7 Rejected Default rejected reason. This should be used if no other match can be found.

False

8 Other To support the Not Applicable action. False



RhBloodGroupPhenotype Code Desciption Definition Deprecated 1 RhD Positive RhD antigen is present on red cells False 0 RhD Negative RhD antigen is not present on red cells False

SexCode See AS4590-2006.

Code Desciption Definition Deprecated 1 Male False 2 Female False 3 Intersex or Indeterminate See AS4590-2006 for more information False 0 Not stated/Inadequately

described False

UnitFate Code Desciption Definition Deprecated 0 NotFinal Any unit status change that cannot be grouped

as a final fate status should use this value. False

1 Transfused Any unit that is Transfused, Assumed Transfused, Confirmed Transfused, or equivalent should use this value.

False

2 Discarded Any unit that is Discarded, Assumed Discarded, Confirmed Discarded, or equivalent should use this value.

False

3 Transferred Any unit that is being Transferred, Prepared for Transferral, In Transit, In Dock, or equivalent should use this value.

False



6 Supporting Information 6.1 Data Element Structure Data elements have been roughly defined around the ISO/IEC 11179.3 Metadata registry metamodel and basic attributes. Where possible the other standards have been adopted for the definition of elements.

6.2 Name The Name is the preferred name of the data element. The Lab Systems Services will be implemented according to this name with the exception of legacy services where the specification will match the preferred name and the legacy services will match one of the synonyms. This will be a single word.

6.3 Synonymous Name Any alternate names for the same data element. The synonymous names will be one or many words.

6.4 Definition A Definition is a statement describing the meaning of the data element.

6.5 Source Standard The Source Standard is a standard that contributes to the definition of the data element or other sources or standards that influence the definition of the data element.

6.6 Data Type The value based data type of the data contained by this element.

Valid date types include:

Data Type Description

Numeric A rational number.

Alphanumeric Numbers, letters, and symbols

Alphabetic Letters and symbols



6.7 Representational Class A Representational Class is a description of the form of the data element.

Valid Representational Classes are:

Representational Class Description

Code A system of valid symbols that substitute for longer values.

Date A numeric value representing a date (YYYYMMDD).

Date and Time A numeric value representing a data (YYYYMMDD) and a UTC time (HH:MM UTC).

Time A numeric value representing a UTC time (HH:MM UTC).

Text Letters, numbers, and symbols taken from a UTF-16 character scheme

Identifier A value that establishes identity within the context of the containing type. In the case of an identity from a different type the representational class would be a Foreign Key or a Code.

Foreign Key A value that forms an identifier of a different type.

Integer A whole number.

Decimal Fixed precision and scale decimal number. Implementation of the storage of this number in a Database will be in the form of a fixed precision and scale number however for the purposes interchange and fact that .NET does not actually have a fixed scale and precision data type built in this will be implemented as a .NET decimal type in the application layer.

Float Decimal numbers with no fixed precision and scale. For the purposes of interchange this will be implemented as a .NET double type in the application layer.

Serial A value that identifies a particular version of a record. While this value will usually increment it is not guaranteed and once the value exceeds the storage size for the number it will be set back to a lower number.

Boolean A true false value. One would be considered true and zero false.

Version A character string representing the version of an application or assembly in the format N.N.N.N where N is a number and the position indicated is Major.Minor.Build.Revision.



6.8 Field Size Maximum The maximum number of characters the element requires to display the value when formatted as a string and/or information about the data size – for example 4 Bytes for an integer. See Implementation of Data Types below for further details.

6.9 Representation Layout The Representational Layout is the format of the data when represented as a string.

6.10 Domain Values Domain Values are a set of values, or a description of a set of values, that are valid for this data type.

6.11 Guide for Use/Examples An example of a valid value for this data element and/or information that further describes the use or interpretation of the data.

6.12 Mandatory Indicates whether a data element is mandatory or not and under which conditions it is. For example whether there are any pre or co-requisites.

6.13 Implementation of Data Types The implementations of value types used within the Lab System Services are based on .NET 4.0 C# simple types and the string (a string is not a .NET simple type). While all attempts are made to ensure changes in the hardware platform and version of the .NET framework do not change these types it is beyond our control and therefore not documented in detail in this specification.

For reference the following sources are the best spot to start for understanding the specific constraints of each of these types.

http://msdn.microsoft.com/en-us/library/ya5y69ds.aspx msdn - Built-In Types Table (C# Reference)

http://msdn.microsoft.com/en-us/library/bfft1t3c.aspx msdn - Value Types Table (C# Reference)

http://msdn.microsoft.com/en-us/library/1dhd7f2x.aspx msdn - Types Reference Tables (C# Reference)

http://msdn.microsoft.com/en-us/library/ya5y69ds.aspx

http://msdn.microsoft.com/en-us/library/bfft1t3c.aspx

http://msdn.microsoft.com/en-us/library/1dhd7f2x.aspx



6.14 References and Standards BloodNet documentation including the user manual and newsletters can be found on the NBA website (www.blood.gov.au/bloodnet/).

The following where referenced throughout the specification:

• NEHTA eProcurement Despatch Advice: http://www.nehta.gov.au/connecting-australia/e-health-procurement

• GS1 XML Standards: http://www.gs1.org/gsmp/kc/ecom/xml/xml_bms • GS1 Despatch Advice: See GS1 XML Standards. • GS1 XML Built-in Types:

http://www.gs1.org/1/productssolutions/ecom/xml/implementation/guide/8_XML_Types.htm • GS1 General Specification, GS1 Application Identifiers (pp. 133-137):

http://www.gs1au.org/assets/documents/info/GS1-General-Specifications.pdf • Independent Hospital Pricing Authority AR-DRG Version 6.x addendum:

http://www.ihpa.gov.au/internet/ihpa/publishing.nsf/Content/CA25794400122452CA257B280015FF6B/$File/AR-DRG-v6%20x-addendum.pdf

• Department of Health and Ageing The Review of the AR-DRG Classification System Development Process: http://www.health.gov.au/casemix

• NEHTA Individual Health Identifiers (IHI): http://www.nehta.gov.au/connecting-australia/healthcare-identifiers

• AS 4590-2006: Interchange of Client Information.

Wherever possible the NEHTA eProcurement standards or the GS1 standards have been followed however we have found some differences or incompatibilities in the data types use and therefore have used our own data types in order to provide the necessary business functions.

6.15 Interpretation of the GS1 Related Standards Some data defined in the NEHTA eProcurement Despatch Advice, the GS1 Despatch Advice, GS1 XML Standards, and the GS1 Application Identifiers may not match the specific requirements for the data within the system, or the data within the system is already not compliant with these standards.

While we have gone to efforts to make sure this data matches there are certain areas where this does not match.

Following are the key changes that have been made to the data types in order to preserve compatibility the data the system uses which may be outside the data definitions in the source standards.

Dates and Date Time The GS1 Application Identifiers do not define DateTime or Time within the standard but the GS1 XML Standards do define it.

http://www.blood.gov.au/bloodnet/

http://www.nehta.gov.au/connecting-australia/e-health-procurement

http://www.nehta.gov.au/connecting-australia/e-health-procurement

http://www.gs1.org/gsmp/kc/ecom/xml/xml_bms

http://www.gs1.org/1/productssolutions/ecom/xml/implementation/guide/8_XML_Types.htm

http://www.gs1au.org/assets/documents/info/GS1-General-Specifications.pdf



http://www.health.gov.au/casemix

http://www.nehta.gov.au/connecting-australia/healthcare-identifiers

http://www.nehta.gov.au/connecting-australia/healthcare-identifiers



BloodNet requires both date and time for some fields (i.e. Expiry Date) which according to all standards only needs to be a date.

Given the data types that will be used for passing date and/or time information to the LIS is based on a .NET DateTime object that does deal with dates and time as a single type and in the above requirements the DateTime data used will always include both a date and a time component.

One other weakness in the standards is clarity on whether times are UTC or local. The GS1 XML Standards indicate that simple types are based upon the W3C XML data types which support date and time with and without a time zone (ISO 8601). An example is when Receipted Issue Notes despatchDateTime does not provide the timezone that it was dispatched from and further information available from the Receipted Issue Note does not indicate the location is was dispatched from, or whether the location is currently operating under daylight savings time.

The result of this is that these times provided by suppliers are not adjusted to UTC but presented as they are presented to BloodNet.

6.16 Technical references for connecting to WCF Sample links below:

• http://social.msdn.microsoft.com/Forums/en/wcf/thread/53db9228-a497-4f33-b40c-1a42cf1cd571 - Consuming WCF Service methods in Java apps

• http://romenlaw.blogspot.com/2008/07/consuming-wcf-web-service-using-java.html • http://hoonzis.blogspot.com.au/2011/07/consuming-wcf-services-with-java-client.html • http://www.kevingao.net/wcf-java-interop/java-client-and-wcf-server.html • http://docs.oracle.com/cd/E17802_01/webservices/webservices/reference/tutorials/wsit/doc/Data

Binding5.html • http://msdn.microsoft.com/en-us/library/cc197940%28v=vs.95%29.aspx • http://msdn.microsoft.com/library/ee958158.aspx • http://www.codeproject.com/KB/aspnet/wcfinjavascript.aspx • http://cgeers.wordpress.com/2009/08/20/using-wcf-services-with-php-5/

http://social.msdn.microsoft.com/Forums/en/wcf/thread/53db9228-a497-4f33-b40c-1a42cf1cd571

http://romenlaw.blogspot.com/2008/07/consuming-wcf-web-service-using-java.html

http://hoonzis.blogspot.com.au/2011/07/consuming-wcf-services-with-java-client.html

http://www.kevingao.net/wcf-java-interop/java-client-and-wcf-server.html

http://docs.oracle.com/cd/E17802_01/webservices/webservices/reference/tutorials/wsit/doc/DataBinding5.html

http://docs.oracle.com/cd/E17802_01/webservices/webservices/reference/tutorials/wsit/doc/DataBinding5.html

http://msdn.microsoft.com/en-us/library/cc197940%28v=vs.95%29.aspx

http://msdn.microsoft.com/library/ee958158.aspx

http://www.codeproject.com/KB/aspnet/wcfinjavascript.aspx

http://cgeers.wordpress.com/2009/08/20/using-wcf-services-with-php-5/



6.17 Example Product Packaging and Codes

Figure 2 BeneFIX 500iu unit packaging top

Figure 3 BeneFIX 500iu barcode

Figure 4 Xyntha 250iu unit packaging top

Figure 5 Xyntha 250ui barcode

No unit packaging top information for Rh (D) IG IM 2VI 250IU Glycine

Figure 6 Rh (D) IG IM 2VI 250IU Glycine

6.18 Reference Table Values This section describes the reference table values at the time of publication. When reference data values are to be updated they will be provided to the LIS administrators via email.

TransferReasons Transfer ReasonID Status Description

1 Close to expiry Close to expiry 2 Patient Transfer Patient Transfer 3 Recall by Supplier Recall by Supplier

4 Unit delivered to incorrect facility by supplier

Unit delivered to incorrect facility by supplier

5 Urgent inventory requirement by other facility

Urgent inventory requirement by other facility

6 Routine distribution to other facility Routine distribution to other facility 7 Other Other



DiscardReason DiscardReasonID Status Description

1 Expired – Time expired Units have exceeded their expiry date/time

2 Expired – Extended life plasma Thawed plasma not used after 5 days

3 Expired – Thawed cryoprecipitate Thawed cryoprecipitate not used after 6 hours

4 Expired – Thawed FFP Thawed fresh frozen plasma not used after 24 hours

5 Damaged – Supplier transit Damaged in transit from the supplier

6

Damaged – Inter hospital / inter lab transit

Damaged in transit between hospitals and/or laboratories. Does not include internal transfers within the same hospital

7 Damaged – Laboratory Damaged in the Pathology laboratory 8 Damaged – Thawing Unit identified as damaged at time of thawing

9 Damaged – Visually unacceptable Unit identified as visually unacceptable

10 Damaged – Transit to ward Damaged in transit to the ward

11 Damaged – On ward Damaged

12 Clinical – Ordered for patient, not required

Unit ordered for a patient being treated however the unit was not required when made available for transfusion

13 Recall – By supplier Unit recalled by the Supplier or Regulator

14 Storage – Refrigeration failure Failure of fridge, freezer or platelet incubator

15 Storage – Out of temperature control

Storage outside of a controlled environment >30 minutes and/or >10 degrees Celsius and/or <1 degree Celsius

16 Storage – Non-compliant storage Storage in known non-compliant environment

17 Storage – Conditions unknown Storage conditions unknown

18

Transport – Temperature failure from supplier

Non-compliant with approved temperature specifications in transit from the supplier

19

Transport – Temperature failure inter hospital / inter lab transit

Non-compliant with approved temperature specifications in transit between hospitals and/or laboratories. Does not include internal transfers within the same hospital

20 Transport – Incorrect packing from supplier

Non-compliant with approved packing specifications from the supplier

21

Transport – Incorrect packing inter hospital / inter lab transit

Non-compliant with approved packing specifications in transit between hospitals and/or laboratories. Does not include internal transfers within the same hospital

22 Transport – Lost in transit Lost in transit

23 Other Discarded for a reason other than those listed above



DiscardLocation LocationID Location

2 Pathology 3 Day Unit

4 Emergency Department

5 Intensive Care Unit 6 Outpatient Clinic 7 Pharmacy 8 Returned to Supplier 9 Theatre

10 Ward 11 Other 12 Unknown

ProductType ProductTypeID ProductTypeCode ProductTypeName

1 A Albumin 2 FC Factor Concentrate 3 IG Immunoglobulin

4 IVIG Intravenous Immunoglobulin

Transfusion Location TransfusionLocationID Value

1 Unspecified

6.19 About BloodNet BloodNet is a web based inventory management system used by pathology laboratories to:

• Order blood and blood products (units) from the Australian Red Cross Blood Service (Blood Service)

• Receipt these units on arrival in the laboratory, providing feedback if required to the National Blood Authority and the Blood Service

• Record the Fate of a unit (i.e. discarded, transferred or transfused) • Provide advice on Inventory levels to inform the management of the national inventory.

Further information on BloodNet (including User Manuals, Training Materials and Newsletters) is available from the NBA website at www.blood.gov.au/bloodnet .

http://www.blood.gov.au/bloodnet



BloodNet is interfaced to the Blood Service eProgesa system (known by the Blood Service as the National Blood Management System or NBMS) and receives electronic information on the contents of deliveries including donor numbers, lot numbers, product codes, expiry dates and some phenotype information. This data also needs to be entered into laboratory information systems. Historically this has been done manually using a combination of bar code scanning and key strokes.

The NBA is currently planning BloodNet interfacing to all other suppliers under the National Blood Arrangements and we anticipate completing this work in 2014. Following this work, feeds of data from these suppliers and inventory holdings of these products will flow through the BloodNet-LIS Interface Web Service APIs.

6.20 Definitions, acronyms and abbreviations Acronym / abbreviation

Description

API Application Programming Interface

Blood Service Australian Red Cross Blood Service

eProgesa The Blood Service National Blood Management System (NBMS)

ERIC Electronic Returns Information Capture

Facility or Laboratory Any source location that places orders with the Blood Service (private and public sector)

JBC Jurisdictional Blood Committee

LIS Laboratory Information System

NBA National Blood Authority

SOAP Simple Object Access Protocol

WCF Windows Communication Foundation

Webservice / Web Service A listening service that receives and processes API calls

WSDL Web Service Definition Language

XML Extensible Markup Language

Component Modifier A descriptive tag applied to a component by the Blood Service or another party that allows sub-classification of a Component

WIF Windows Identity Foundation. A library for token and claim based authentication.



Acronym / abbreviation

Description

Unit An individual item of comprising of a Blood Component (for example Red Cells) or a manufactured Blood Product (for example IVIg).

Facility Web Site The BloodNet website. Used by Laboratory Users for Ordering, Receipting, and Fate.

BURG BloodNet User Reference Group.

bloodnet – lis interface web service apis specification · bloodnet – lis interface web service...

Documents