EMDIS Cord Status 2011 04-01 v1.1

19
EMDIS-Cord Technical Committee Status 1-April-2011

description

Update of the EMDIS Cord Pilot Project presented to the EMDIS Users Groups at the WMDA meetings in Paris (April 2011).

Transcript of EMDIS Cord Status 2011 04-01 v1.1

Page 1: EMDIS Cord Status 2011 04-01 v1.1

EMDIS-CordTechnical Committee Status

1-April-2011

Page 2: EMDIS Cord Status 2011 04-01 v1.1

EMDIS-Cord Overview

07/01/112

Officially created on 18 December 2008 as supplementary action to EMDIS

The goal of EMDIS-cord, based on the sharing of Cord Blood Unit (CBU) data, is to provide global CBU searching that is: Current (up to date inventory),

Comprehensive (all relevant fields increase in efficiency),

Real-time (updating of data available everyday on line increase in speed).

Integrated results (data from all participating registries in one list)

and to develop a common set of data for cord blood unit reports, to be put into EMDIS.

Page 3: EMDIS Cord Status 2011 04-01 v1.1

EMDIS Cord Pilot Project

07/01/113

EMDIS Cord mirroring - technical pilot Purpose: To determine if the exchange and mirroring of inventory is

feasible

Involved: 6 pilot EMDIS cord registries

EMDIS Cord messaging improvement Purpose: Support cord messaging by separating cord and donor

messages where required and expanding values and fields where possible

Involved: Spearheaded by the business representatives of the six EMDIS Cord registries in the pilot project.

* This effort introduces CBU_FULL and CBU_DIFF messages for exchange of full and differential inventory updates. These and other messaging changes will require an EMDIS IP.

Page 4: EMDIS Cord Status 2011 04-01 v1.1

Benefits Expected Incoming – Receiving Inventory from other Registries:

Improve the value of the “local” registry search more timely more comprehensive more complete reduce time for TC to narrow cord choices

Improve timeliness and accuracy of cord activity requests through automation

Outgoing – Sending Inventory to other Registries: Increase visibility of inventory

Overall: Operational efficiencies achieved per cord activity request through

automation

Further international collaboration

07/01/114

Page 5: EMDIS Cord Status 2011 04-01 v1.1

Expected Frequencies/Volumes

07/01/115

Question FGM ZKRD IBMDR REDMO Europdonor NMDP

How many cords are expected in first full inventory update?

~10,000 8300 >22,000 ~50,000 ~3000 130,000

How frequently will differential updates be sent?

5 times/day

Hourly Daily at least Once a day Daily Hourly

How many differential updates expected on a daily basis?

Between 10 and 150

Between 0 and 100

Between 0 and 80 (average)

Between 1 and 200

TBD Between 550 and 750

Page 6: EMDIS Cord Status 2011 04-01 v1.1

Considerations (updated)

07/01/116

Pace/cadence of differential updates At least daily

Pace/cadence of full updates At least every 6 months

Inventory synchronization verification Periodic request of full inventory update with evaluation of three

conditions: Cord is in mirrored inventory (with non-deleted status), but not in the full inventory update Cord is in full inventory update, but not presently in mirrored inventory Cord in full inventory update with different values than in the mirrored inventory

All scenarios must generate a warning and associated remediation A ‘synch’ report may be generated

Page 7: EMDIS Cord Status 2011 04-01 v1.1

Inventory Synchronization Verification

07/01/117

EMDIS Partner

(Mirrored Inventory)

EMDIS Partner (Source

Inventory)

Admin Request for CBU_FULL

CBU_FULL upon request

1. Cord is in mirrored inventory with non-deleted status but not in CBU_FULL

2. Cord is in CBU_FULL but not in mirrored inventory

3. Cord is in CBU_FULL with different values than mirrored inventory

WarningBehavior of mirrored registry to keep or remove mirrored cord for scenario 1 does not presently have unanimous agreeement, making it a local concern.

Synch Report

Page 8: EMDIS Cord Status 2011 04-01 v1.1

Development Progress

07/01/118

Since the Fall 2010 EMDIS UG meeting: The total number of tasks marked green increased just over 100%

The total number of tasks marked red decreased 50%

The total number of tasks marked yellow remained about even

Tracking additional data point for each registry: The ability to validate and return automated feedback for incoming

inventory messages (CBU_FULL or CBU_DIFF)

Ready

Development in Process

Not Started

Development complete, ready to test discrete message

Development in progress

Development not started, development on hold, or not indicated

Legend

Page 9: EMDIS Cord Status 2011 04-01 v1.1

Development Progress

07/01/119

https://donatori.galliera.it/emdiscord/

Task Europdonor FGM IBMDR NMDP REDMO ZKRDStatus Status Status Status Status Status

Environment setup Ready Ready Ready Ready Ready Ready

ECS - Multi Part Email Ready Ready Ready Ready Development in Process

Ready

 

Send NEW_ADD Messages (sending Bank/Accreditation)

Development in Process

Ready Ready Ready Not Started Not Started.

Send CBU_FULL Messages Development in Process

Ready Ready Ready Development in Process

Ready

Send CBU_DIFF Messages Development in Process

Ready Ready Ready Development in Process

Ready

Send Request/Response Messages/RES_NOT Development in Process

Development in Process

Not Started Ready Not Started Development in Process

 

Receive NEW_ADD Messages Development in Process

Development in Process

Ready Ready Not Started Development in Process

Receive CBU_FULL Messages Development in Process

Ready Ready Ready Not Started Ready

Receive CBU_DIFF Messages Development in Process

Development in Process

Not Started Ready Not Started Ready

Validate CBU_FULL, CBU_DIFF, return warnings/errors

Ready Ready

Display match lists, requests and results Not Started Development in Process

Not Started Development Paused

Not Started Not Started

Receive Request/Response Messages/RES_NOT Not Started Development in Process

Not Started Development in Process

Not Started

Page 10: EMDIS Cord Status 2011 04-01 v1.1

Anecdotal Observations

07/01/1110

Many registries chose to implement outbound messaging first This has limited the ability to provide feedback on exchanged messages

Development progress indicates that more frequent test message exchange is possible/likely this summer

Many fields in inventory messages are not populated These are optional fields

May drive the need to consider a shared ‘test’ message set for participating registries

Competing Priorities WHO Nomenclature V3 compliance

EMDIS IP8

Local Priorities

Page 11: EMDIS Cord Status 2011 04-01 v1.1

Resources

07/01/1111

dotProject collaboration site - http://emdis.nmdp.org EMDIS-Cord Data Dictionary – Updated (v.1.3.6)

EMDIS-Cord Semantics – Updated (v.1.2.2)

EMDIS-Cord Project Plan (v1.4)

Available ECS Implementations http://sourceforge.net/projects/perlecs/ - Perl ECS 0.31

http://steinersw.cz/sw/ester/ - ESTER EMDIS-Cord 1.0

IBMDR

REDMO

Page 12: EMDIS Cord Status 2011 04-01 v1.1

Appendix A

EMDIS Cord Technical Committee Visuals

07/01/11Confidential and Proprietary – Internal Distribution Only

12

Page 13: EMDIS Cord Status 2011 04-01 v1.1

UX Test Hub ECS Traffic

07/01/1113

Received (Inbound) Transmitted (Outbound)

Node ADMIN CBUFULL

CBUDIFF

NEWADD

LastDate

ADMIN CBUFULL

CBUDIFF

NEWADD

LastDate

DX - 3 - - Sep 8 1 3 1 - Jan 25

ES - - - - - - - - - -

FX 3 1 5 1 Mar 10 - 2 - - Dec 13

IX 1 5 15 - Feb 25 1 1 - - Feb 11

XX 2 - - - Dec 23 - 2 - - Dec 30

Page 14: EMDIS Cord Status 2011 04-01 v1.1

Conceptual Solution CBU_FULL

07/01/1114

EMDISPartner(Source

Inventory)

CBU_FULL at start-up/upon request

ADMIN request for CBU_FULL

EMDISPartner(Mirrored Inventory)

An inventory message will include additional fields to provide more comprehensive information for selecting a cord.

The “Local” EMDIS Registry will request full inventory from the “Remote” EMDIS Registry.

The “Remote” EMDIS Registry will send their full inventory.

Page 15: EMDIS Cord Status 2011 04-01 v1.1

Conceptual SolutionCBU_DIFF

07/01/1115

CBU Bank

New CBU Updated CBU Deleted CBU

EMDIS Partner (Source Inventory)

EMDIS Partner (Mirrored Inventory)

Mirrored Inventory

New CBUUpdated CBU

Deleted CBU

The “Remote” EMDIS Registry will continue to send updates to their inventory (new CBU’s, deleted CBU’s, changed CBU’s). (The minimum update frequency is daily; preferred is as close to real-time as possible.)

Page 16: EMDIS Cord Status 2011 04-01 v1.1

Conceptual SolutionRSV_NOT

07/01/1116

EMDIS Partner

( Source Inventory )

EMDIS Requesting

Partner ( Mirrored Inventory)

MSG _ ACK

RSV _ NOT

_MSG_DEN, NO_RES

TYP_REQ/SMP_REQ/IDM_REQ/WOR_REQ**

Proposed RSV _ NOT Message Flow

** WOR _ REQ or new Cord Order Request message

:

PAT _ UPD

• The “Local” EMDIS registry will search the “mirrored” inventory and display matches on their up-front search report.

• When a Transplant Center is interested in a cord, the “Local” EMDIS Registry ensures that the “Remote” EMDIS Registry has the most current patient information and patient status, and then proceeds with requests as usual.

Page 17: EMDIS Cord Status 2011 04-01 v1.1

Appendix B

EMDIS Cord Business User Group

07/01/11Confidential and Proprietary – Internal Distribution Only

17

Page 18: EMDIS Cord Status 2011 04-01 v1.1

Accomplishments since October 2010:(Business User Group Representatives)

07/01/1118

Reviewed and accepted the following recommendations from the EMDIS Cord Technical Committee. Examples: Frequency of CBU_FULL Mirroring hub to request CBU_FULL no less than every 6 months.

Frequency of CBU_DIFF As noted in the Semantics document, minimum is daily

Handling differences with the second, and subsequent CBU_FULL messages

Considered “error conditions”.

Security Agreement language A few modifications were made

One more change will be required regarding ending the agreement Allowing request for removal of inventory from mirroring registries

Page 19: EMDIS Cord Status 2011 04-01 v1.1

Accomplishments since October 2010:(Business User Group Representatives)

07/01/1119

Modified the EMDIS Cord Data Dictionary and Semantics to add clarity to some definitions. Examples: Definition of CB_CFU to specify that it is Post-Processing, GM Method.

When a typing or sample request is received, CB_STATUS will be RE, and CB_STAT_END_DATE will be 60 days from the date of the typing or sample request. This will indicate the unit is “Temporarily Reserved”.

Additional values for CB_HEMO_STATUS.

Expand the CB_VIABILITY definition to specify it is for Total Nucleated Cell Count.