msupply-foundation / unified-codes

Provides a curated, searchable list of pharmaceutical products, each with an immutable code. A GraphQL API, a REST API and website are available for interaction with the database.
https://codes.msupply.foundation
2 stars 0 forks source link

International price benchmarks #7

Open kat-ms opened 4 years ago

kat-ms commented 4 years ago

Background (from MFAT Proposal)

Provide a source of anonymised reference pricing data, helping countries to ensure prices offered are fair.

Description

Placeholder issue to discuss/plan out how we will handle pricing data (for drugs being bought/sold within mSupply) and the Universal Codes application.

Goal

Consensus on approach. This will form the basis for separate sub-issues to build it out.

Requirements

Current Discussion Points/Agreements

wlthomson commented 4 years ago

Thanks for documenting this requirements, really helpful! I don't know too much about this area of functionality, but looks good to me!

I think this could be something to put into the MVP, but as this stage my thoughts are it might be something for after the initial core functionality is implemented and approved?

kat-ms commented 4 years ago

Yeah, probably not one to start early on until we have the core ironed out, as long as the schema can accomodate prices, then I think we should be ok?

mark-prins commented 4 years ago

yes; I'd leave out of MVP. it's important for sure, but a large job with a few moving parts. Best to leave it as a separate item of work, and to look at it after MVP.

wlthomson commented 4 years ago

Yeah, so I think concensus from all of us is that this functionality is something to keep in mind when working on the MVP, but not something we need to implement for it?

Re. the schema, I don't think prices will be too tricky 🤞 . Current thinking is to either add prices onto the schema just like other property nodes (would definitely need a type field, and perhaps additional fields for currency etc.), or to add a new node type just for prices (and maybe a new relation, e.g. has_price).

Something to be agreed later, but main point is that I think it should be relatively straightforward to extend the MVP schema to additional functionality like prices 👍.