Medication Definition profiling

[rlindstrm]

We've been working on Pilot Product List profiles (based on what we agreed for UFIS). I understand Datawizard is also profiling (probably understood wrong), but possibly someone is. This is my work, some final things unfinished, some issues that I'd like to discuss. Please give me a sign if you're interested in collaborating on this or you see how we could combine our efforts.

1) Logical model for our UFIS PPL product a. Based on ISO IDMP logical model. b. Published as a FHIR resource (the Logical Model meta-resource, not the Medication Definition resources) c. Code published in UNICOM IG Github (mpd-r5 branch).

2) Profiles with a few examples for PPL/UFIS a. These are based on FHIR v 5.0.0 Ballot, which is the newest at the moment b. UFIS products in UFIS are right now in FHIR 5.0.0 Snapshot, which is already not supported by tools. We are thinking about moving to the newer version. I'm interested in collaborating with some technically advanced people to automate this. c. The content of the profiles is entirely based on EMA IG and follows what we agreed on in UFIS/PPL meetings. d. I have used the open approach: restricting and describing the part that is in the logical model, but leaving the rest of the FHIR spec open for others to use differently (for example, add more data). e. There are a few minor issues, which I did not manage to solve on my own. I will get someone to help me with shorthand syntax. f. Code published in UNICOM IG Github (mpd-r5 branch).

[Censacrof]

Hi, i'm working on T6.1 and i think we should combine our efforts indeed. Please @rlindstrm, let me know how I can help you.

First, I wasn't aware of the Logical Model meta-resource (i'm not expert yet in FHIR), and I think it's very cool that it exists and we should use it for the specification. I suggest that, at least for the moment, we focus on the IDMP attributes that are part of the MAL. For the T6.1 we came up with our own datamodel, based on IDMP restritcted to the MAL, but there are issues with it (for example #27 ). I think that we should work togeher on the Logical Model and add it to the UNICOM IG.

UFIS products in UFIS are right now in FHIR 5.0.0 Snapshot, which is already not supported by tools.
We are thinking about moving to the newer version. I'm interested in collaborating with some technically
advanced people to automate this.

It shouldn't be hard to do, as long as you have a clear understanding of differences between the two versions, I think I can help you with that.

[costateixeira]

Hi Rutt

Thank you and sorry for my late reply. I think that this work is cornerstone for collaboration because you see the IDMP model and issues, and also the interface between that and the eHDSI, etc.

On the UFIS - R5.0.0-snapshot1, I am now more free to get back to this. I guess the biggest decision is whether we do R5.0.0-snapshot1 and R5.0.0-ballot going forward. (we already have an issue for that)

Once we do it , we have it easy - and if we agree, we can just create an issue and then we can work on it together:

1. Convert the examples to json (which has the bonus of validating)
2. Then convert to FSH
3. Global search-replace FSH for the differences
4. Re-sushi the whole thing (well, as part of the IG, then we keep control of the changes) (I already ran the process once, so I know the pain points - spoiler alert: it's #1)

Francesco - I presume by "MAL" we are talking about the model documented in the 5.7 branch? Not a problem if not, we need to reconcile more stuff anyway.

Cheers

On Wed, Nov 2, 2022 at 5:28 PM Francesco Galisi @.***> wrote:

Hi, i'm working on T6.1 and i think we should combine our efforts indeed. Please @rlindstrm https://github.com/rlindstrm, let me know how I can help you.

First, I wasn't aware of the Logical Model meta-resource (i'm not expert yet in FHIR), and I think it's very cool that it exists and we should use it for the specification. I suggest that, at least for the moment, we focus on the IDMP attributes that are part of the MAL. For the T6.1 we came up with our own datamodel, based on IDMP restritcted to the MAL, but there are issues with it (for example #27 https://github.com/hl7-eu/unicom-ig/issues/27 ). I think that we should work togeher on the Logical Model and add it to the UNICOM IG.

UFIS products in UFIS are right now in FHIR 5.0.0 Snapshot, which is already not supported by tools. We are thinking about moving to the newer version. I'm interested in collaborating with some technically advanced people to automate this. It shouldn't be hard to do, as long as you have a clear understanding of differences between the two versions, I think I can help you with that.

— Reply to this email directly, view it on GitHub https://github.com/hl7-eu/unicom-ig/issues/30#issuecomment-1300834278, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD3HUUFS6V5NBCSZN2AYLEDWGKJBNANCNFSM6AAAAAARU6VBTY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[Censacrof]

I presume by "MAL" we are talking about the model documented in
the 5.7 branch? 

@costateixeira By MAL I mean the Minimum Attribute List:

[rlindstrm]

Your MAL is practically the same as our PPL product data. And it is not a coincidence. :) The main difference is that you would need EDQM and UCUM, while EMA happily uses SPOR codes everywhere (EVERYWHERE!). Whatever is the thing you're building, our data needs to work for your project too, otherwise we cannot talk about interoperability in the data chain. :)

Right now we've added coding slices for ATC, Country and Language to allow SPOR as well as normal codes, but I have been contemplating whether I should go more generic with the profiles and allow EDQM as well. Then we could pretty much use the same profiles. Also, we included package material information, which itself is not needed by anyone, but we wanted to show that the PCID is dependant on the package material. Two identical packages of the same product would have different PCIDs if one is in a blister of Aluminium+PVC and the other one just Aluminium+Aluminium.

I have successfully (manually) converted some products from 5.0.0 snapshot to ballot to include them in the profile examples. It's very easy, changes are small. However, there is an actual need for 4.6->5.x conversion at some point, I think. This will be much more difficult to handle.

José made me do the logical model, promising that we will do some version mapping exercise with it. We'll see. :)

[costateixeira]

Hi

The MAL model is expressed as a LM here https://build.fhir.org/ig/hl7-eu/unicom-ig/branches/D5.7/StructureDefinition-MinimumAttributeList.html#tabs-diff

I really hope it corresponds to that table because that is where I got it from

Thanks

On Wed, Nov 2, 2022 at 6:02 PM Francesco Galisi @.***> wrote:

I presume by "MAL" we are talking about the model documented in the 5.7 branch?

@costateixeira https://github.com/costateixeira By MAL I mean the Minimum Attribute List:

[image: image] https://user-images.githubusercontent.com/15619279/199554009-df270258-8656-4fc5-92a7-3e65e8955224.png

— Reply to this email directly, view it on GitHub https://github.com/hl7-eu/unicom-ig/issues/30#issuecomment-1300919578, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD3HUUHOSSI2OT4ZV74ICS3WGKNDVANCNFSM6AAAAAARU6VBTY . You are receiving this because you were mentioned.Message ID: @.***>

[rlindstrm]

The problem with MAL is the L. :) IDMP structure cannot be squeezed into a list. That MAL logical model you show would for example not work with combination packages: one product containing two different pharmaceutical products (like in my examples Canifug Cremolum is: cream + pessaries within one package).

[costateixeira]

Thanks. I guess neither does the table in the doc support it, right? We should have a Logical Model of the Minimum Attribute Structure (MAS?) and that link was intended to be it. If we need to improve it, I can add this as a separate issue.

Is that a good way forward?

On Wed, Nov 2, 2022 at 7:08 PM rlindstrm @.***> wrote:

The problem with MAL is the L. :) IDMP structure cannot be squeezed into a list. That MAL logical model you show would for example not work with combination packages: one product containing two different pharmaceutical products (like in my examples Canifug Cremolum is: cream + pessaries within one package).

— Reply to this email directly, view it on GitHub https://github.com/hl7-eu/unicom-ig/issues/30#issuecomment-1301030303, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD3HUUEO5PSFXYVKQAPF6X3WGKUYRANCNFSM6AAAAAARU6VBTY . You are receiving this because you were mentioned.Message ID: @.***>

[rlindstrm]

There is no such thing as MAS or MAL in the world, therefore it cannot have a logical model of its own.

You can have a logical model for eHDSI implementation, XYZ implementation, or, if you want to be implementation-agnostic, you should use our PPL one, which conforms to ISO IDMP and represents data as it should be at the original source.

[Censacrof]

@rlindstrm

Your MAL is practically the same as our PPL product data. And it is not a coincidence. :)

First of all, it's not "my" MAL, as I am not the one who made it. I think the MAL was the output of another taske in the project, not lead by Datawizard, way before I joined the project. To me was presented as a requirement when I started to work on the project, and until now I believed everyone was aware of it.

The main difference is that you would need EDQM and UCUM, while EMA happily uses SPOR codes everywhere(EVERYWHERE!). Whatever is the thing you're building, our data needs to work for your project too, otherwise we cannot talk about interoperability in the data chain. :)

Yes, I know. Luckily, when it comes to EDQM its very easy to convert to from one coding to the other, this is because the SPOR coding is based on the EDQM one. For example, if you go to the SPOR page for PharmaceuticalDoseForm:

as you can see there are two columns: Identifier and Source Id. The first one contains the SPOR codes for PharmaceuticalDoseForm, while the other contains the corresponding EDQM codes. I'm not sure why they did this instead of directly using the EDQM code system, but I'm sure they had their good reasons.

Also, we included package material information, which itself is not needed by anyone, but we wanted to show that the PCID is dependant on the package material. Two identical packages of the same product would have different PCIDs if one is in a blister of Aluminium+PVC and the other one just Aluminium+Aluminium.

Oh, didn't know that. My understanding is that right now we don't have MpIds or PcIds. If I understood correctly right now we only have some "candidate" PhpIds (for a very limited set of products), generated using different algorithms. Am I wrong about this? If the IDMP identifiers were available our lives would be a little bit easier.

I have successfully (manually) converted some products from 5.0.0 snapshot to ballot to include them in the profile examples. It's very easy, changes are small. However, there is an actual need for 4.6->5.x conversion at some point, I think. This will be much more difficult to handle.

Good Job. I think we really need to decide which version of FHIR to use (#3).

---

@costateixeira

The MAL model is expressed as a LM here https://build.fhir.org/ig/hl7-eu/unicom-ig/branches/D5.7/StructureDefinition-MinimumAttributeList.html#tabs-diff

I really hope it corresponds to that table because that is where I got it

Oh, that's nice. I wasn't aware of it. Tomorrow il will check if it corresponds.

---

@rlindstrm

The problem with MAL is the L. :) IDMP structure cannot be squeezed into a list. That MAL logical model you show would for example not work with combination packages: one product containing two different pharmaceutical products (like in my examples Canifug Cremolum is: cream + pessaries within one package).

The aim of the MAL it's not of course to convey information about the structure of data. The structure of data is dictated by IDMP already. The MAL is something that tells us which of the attributes contained in the entities of IDMP is relevant for us.

---

@costateixeira

Thanks. I guess neither does the table in the doc support it, right? We should have a Logical Model of the Minimum Attribute Structure (MAS?) and that link was intended to be it. If we need to improve it, I can add this as a separate issue.

Is that a good way forward?

Seems a very good idea to me. As I already said, we need to agree on a Logical Model / Data Model based on IDMP restricted to the MAL. If you open another issue I will share the data model we implemented for the T6.1 database.

---

@rlindstrm

There is no such thing as MAS or MAL in the world, therefore it cannot have a logical model of its own.

You can have a logical model for eHDSI implementation, XYZ implementation, or, if you want to be implementation-agnostic, you should use our PPL one, which conforms to ISO IDMP and represents data as it should be at the original source.

If I understood correctly, in the real world IDMP data does not exists yet (save for a few exceptions). If we use the full IDMP standard, its going to be a pain. Most of the attributes will be missing anyway. I think this is the reason why they created a MAL, it's a simplification that allows us to start working on something that will need to be improved in the (far?) future. I personally agree with this: lets start with something simple and then we will improve it.

Thank you for this very constructive discussion!

[rlindstrm]

We, in Estonia, were the silly ones who actually implemented full ISO IDMP in our national database. :) But yes, you're right about identifiers. We(EE, SE) created fake ones for our testing data in UFIS.

If you look at our logical model, then it conforms to ISO IDMP, but it's definately very far from full ISO IDMP as it is used in the regulatory domain. And I'm sorry for calling it your MAL. I know it's not your invention but an official deliverable. I'm just a little blunt in expressing myself. :)

I have been relieved to read that your structure comes from real IDMP and not MAL. It was a long-term misconception that this data could be flattened to a list of attributes and distributed Excel sheet style. My bitter comment about this was addressed to José who is already trained to hear it.

So, I might sound bitter here and there, but that's just because I am. I am also incredibly happy to have these discussions. I would be glad to see your data model and think along here and there. Maybe we could have a call sometimes. and compare our findings.

And I'd be very happy if we could collaborate on FHIR value sets and code systems, because this has become a blocker issue to my profiling work. I will make a new issue for that. :)

[Censacrof]

And I'm sorry for calling it your MAL. I know it's not your invention but an official deliverable. I'm just a little blunt in expressing myself. :)

Don't be sorry, I wasn't offended by that :), also you don't sound bitter at all to me.

And I'd be very happy if we could collaborate on FHIR value sets and code systems, because this has become a blocker issue to my profiling work. I will make a new issue for that. :)

Of course, I will be happy to help.

[costateixeira]

Making the valuesets and corresponding codesystems is a) extremely simple to do in an implementation guide b) extremely silly to do outside the existing implementation guide (because the profiles will use it for validation)

Here's an issue https://github.com/hl7-eu/unicom-ig/issues/32

Do you have the CSVs with the list of values (and the adequate permissions etc) that we need? I can try to bring a simple template tomorrow

So if we have the CSVs we can add them to the IG very easily. And since we do have a running server, we get some terminology services for free :)

Rutt, do you have availability (and interest) in joining the technical call tomorrow at 10h30 Belgian time?

On Thu, Nov 3, 2022 at 12:45 PM Francesco Galisi @.***> wrote:

And I'm sorry for calling it your MAL. I know it's not your invention but an official deliverable. I'm just a little blunt in expressing myself. :)

Don't be sorry, I wasn't offended by that :), also you don't sound bitter at all to me.

And I'd be very happy if we could collaborate on FHIR value sets and code systems, because this has become a blocker issue to my profiling work. I will make a new issue for that. :)

Of course, I will be happy to help.

— Reply to this email directly, view it on GitHub https://github.com/hl7-eu/unicom-ig/issues/30#issuecomment-1301981621, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD3HUUAFBIIYPUF3ZK3TBH3WGOQU5ANCNFSM6AAAAAARU6VBTY . You are receiving this because you were mentioned.Message ID: @.***>

[Censacrof]

I have the CSV for all needed valuesets (SMS, EDQM) but not UCUM (which is not finite so it will need something like a regex to validate).

[rlindstrm]

With SPOR codes? (I listed my biggest needs here)

[Censacrof]

I will reply in that issue soon

[costateixeira]

UCUM is part of the FHIR validator, we do not need to describe a valueset

On Thu, Nov 3, 2022 at 4:42 PM Francesco Galisi @.***> wrote:

I will reply in that issue soon

— Reply to this email directly, view it on GitHub https://github.com/hl7-eu/unicom-ig/issues/30#issuecomment-1302304036, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD3HUUAWRJOH4PHYWV7ZUOTWGPMPBANCNFSM6AAAAAARU6VBTY . You are receiving this because you were mentioned.Message ID: @.***>

[rlindstrm]

UCUM is part of the FHIR validator, we do not need to describe a valueset

I still need UCUM with SPOR codes, remember? :) I'm from the other side...

[costateixeira]

This is beautiful. This is like "make a list of all the words that mankind can ever use"...

Oh well, then we need a list of values, no RegEx. CSVs please?

On Thu, Nov 3, 2022 at 6:03 PM Rutt @.***> wrote:

UCUM is part of the FHIR validator, we do not need to describe a valueset

I still need UCUM with SPOR codes, remember? :) I'm from the other side...

— Reply to this email directly, view it on GitHub https://github.com/hl7-eu/unicom-ig/issues/30#issuecomment-1302411886, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD3HUUHBVR3GCULJRUUWJKDWGPV6TANCNFSM6AAAAAARU6VBTY . You are receiving this because you were mentioned.Message ID: @.***>

[rlindstrm]

Profiles done (will evolve): https://build.fhir.org/ig/hl7-eu/unicom-ig/branches/mpd-r4b/artifacts.html Value sets either done or covered by other issues.