Refining the calculate operation

[jkiddo]

Regarding https://github.com/hl7-eu/gravitate-health/blob/2dbc92d3c685a920421527446074639aa6043dd0/input/fsh/profiles/operation-calculate.fsh --

We need to revise the operation so that https://github.com/hl7-eu/gravitate-health/blob/2dbc92d3c685a920421527446074639aa6043dd0/input/fsh/profiles/operation-calculate.fsh#L26 is not an ePI bundle, but instead a (global) identifier for the ePI. FOSPS (the backend G-lens service) should be able to reckonize this and fetch the ePI itself from some trusted source. @gcangioli / @costateixeira would that ideally be a IDMP identifier or something else?

[gcangioli]

I think it depends n what we'd like to achieve and what could be available. I mean is responsibility of the operation to search for all the possible ePI fulfilling that identifier (e.g. a PhPID) ? I hope not ..

or this identifier is one of the identifiers of the products used in the subject list ? (MPID, PCID)

[jkiddo]

I think of it as the identifier identifying the ePI - whatever that may be

[cander2]

Not an IDMP identifier because IDMP refers to the product(s) inside the ePI. The Bundle id would be a ideal for this. That is what what uniquely identifies the instance of the ePI document approved by the health authority.

[jkiddo]

It cannot be the bundle id. id's cannot be used to identify anything in a global setting

[cander2]

ok, Bundle Identifier then? Looking at the resource and it looks like that is what it is for

[jkiddo]

yep - and what global/semi global/regional identifier would that origin from?

[cander2]

For FDA and Health Canada it would be a uuid assigned by the author. This would be the @id_root from their current SPL documents.

EMA hasn't defined how this would work yet but I would recommend they align with FDA and HC by having the author assign a uuid.

[cander2]

I think it depends n what we'd like to achieve and what could be available. I mean is responsibility of the operation to search for all the possible ePI fulfilling that identifier (e.g. a PhPID) ? I hope not ..

or this identifier is one of the identifiers of the products used in the subject list ? (MPID, PCID)

Regarding what we would like to achieve, majority of people will just want the current ePI for a given product in a particular language.

Other use cases involve research, lawsuits, analytics, pharmacovigilence. For these topics, people might want to get specific ePI versions or get all ePIs in a set (e.g., all humalog ePI versions and translations).

Yes, some might indeed do a search for all ePIs with a certain PhPID. That would be like a pharmacovigilance situation where class labelling is being considered.

[gcangioli]

sorry .. now I'm little bit confused :-)

what this operation is for ? My understanding was that is was for the FOSPS, so used by the patient to get an "enhanced/personalized" version of the ePI

From what I understood the input should be an ePI business identifier (instance identifier ? or document identifier ?), that means that other services will be used for obtaining this ePI identifier based on the product identifiers/identification attributes.

Is this is what we want ?

I believe that we should before consolidate the business/functional requirements and then see what are the services ('plain' FHIR API or ad hoc FHIR operations) that we need to specify to get there :-)

[jkiddo]

what this operation is for ? My understanding was that is was for the FOSPS, so used by the patient to get an "enhanced/personalized" version of the ePI

From what I understood the input should be an ePI business identifier (instance identifier ? or document identifier ?), that means that other services will be used for obtaining this ePI identifier based on the product identifiers/identification attributes.

I would agree to the above

[jkiddo]

Separating the discovery/search of the identifier enables us to focus on what input and output of the operation is

[jkiddo]

And it helps us isolate what we need to do where

[cander2]

@jkiddo , @gcangioli , can we close this one?

[jkiddo]

Id say so