Requirements for M36 - Githubissues

wed, 2022-02-02 14:24
Dear PDM,

As integration of Anti-Counterfeiting and ePI proceeds, the use case team (business) has focused on ACDC. We have identified what is currently missing or could be adopted/integrated from other use cases (ePI, FGT).

Below is the list. We can go through this on the Friday tech meeting for clarity. 

    ACDC Data Input. Additional ACDC data requirements from original (ePI) scan:

This is what ACDC receives now:

  "productCode": "02113100000011",

  "batch": "MAY1701",

  "serialNumber": "43023992515022",

  "expiryDate": "29 - Apr - 2022",

  "snCheckDateTime": "2022-01-25T10:13:47.143Z",

  "snCheckLocation": {

    "latitude": 37.09024,

    "longitude": -95.712891,

    "altitude": null,

    "accuracy": 1489640.756336928,

    "altitudeAccuracy": null

  },

  "batchDsuStatus": true (check 1)

We would like to add the following checks:

"expiryDatecheck":  true (check 2) is the scanned expiryDate matching the registered expiryDate? (true/false)

"authfeature?":  true (check 6, part 1) does the scanned product have a authentication feature? (true/false)

    ACDC check results. Additional ACDC resolution/checks:

This is what ACDC check results currently returns:

"snCheckResult": "Authentic", (check 3)

  "nameMedicinalProduct": "Cosentyx",

  "productStatus": "Released to market"(check 4)

  "mahId": "0c1aec99-a17f-495d-adfc-008888baef6c",

  "mahName": "Novartis AG"

We would like to make the Product Status availability from FGT? (check 4) actually a real on-line check.  Is it possible to integrate this now or soon from the FGT environment?

    Authentication feature check results. (check 6, part 2 – the actual result from AlpVision/TrueMed/INCM) - can the results of the feature check be written to ACDC, and linked somehow to the original scan transation? This is a separate transaction/record in ACDC.  
    ACDC business rule check (check 5). We would like to demonstrate one easy (configurable) business rule check.  The proposal is that t[here](https://upm365.sharepoint.com/:w:/r/sites/PharmaLedger/Documentos%20compartidos/DRA1_eLeaflet%20Use%20Case/C.%20Anti-Counterfeiting/Use%20Case%20Description%20and%20Volere/2022_01_28_PharmaLedger_Anti-Counterfeiting_Use-Case-Description%20v2.1.docx?d=wa48c06a6c31345a29562ef96cddf337e&csf=1&web=1&e=S5hK3G) is a known product/batch that is always counterfeited (the counterfeiters just change the expiry and serial numbers). Anytime that this batch is scanned, ACDC would register this and return an alert to the user. This could be hardcoded for demo purposes or there is an option to enter or tag a batch as suspect.
    ACDC data segreation.  ACDC should provide only the individual MAH’s product data (when the scan is able to resolve to that MAH). In the demonstrator, currently all data is captured from all MAH’s.  We guess that this is because there is only one Enterprise Wallet.  How will different instances of ACDC be implemented? Does this happen automatically? What about unregistered products (no Enterprise Wallet DSU entry).  How could that be routed to a future PharmaLedger-specific instance of ACDC?  One future scenario is that the PharmaLedger Foundation maintains its own ACDC repository of scan transactions that cannot be resolved to a specific MAH.  Is that possible?
    SSO.  Is it possible to leverage the ePI Single Sign On (SSO) solution/integration (used to manage access to the enterprise wallet) for ACDC access? We understand that this would allow for the same type of integration to an enterprise IAM system. This would make the solution that much easier for future adoption.

Please have a look and we can discuss on Friday as time allows. The updated Use Case description is here.  Question will also be if we need to update the STS.

Many thanks!

Dan
PharmaLedger-IMI / acdc-components

Requirements for M36 #21
