FHIR Chat · Medication element with multiple code systems · implementers

Stream: implementers

Topic: Medication element with multiple code systems

Pranitha Sruthi (Dec 06 2017 at 09:47):

Hi all, how can an element in the Medication refer to multiple code systems (RxNorm, NDC,SNOMED CT etc)? Thank you

Jose Costa Teixeira (Dec 06 2017 at 10:55):

Hi. AFAIK, it can't :)
And AFAIK, It shouldn't (not directly) - that association may be context-sensitive. e.g. a same medication can be in two ATC classes, depending on its use.

Jose Costa Teixeira (Dec 06 2017 at 10:55):

The work on Catalog is supposed to suport exactly this.

Jose Costa Teixeira (Dec 06 2017 at 11:02):

http://build.fhir.org/entrydefinition.html supports additional classifications and identifiers

Pranitha Sruthi (Dec 06 2017 at 11:02):

I did not understand. Can you elaborate? What if the same medication is in two classes?

Jose Costa Teixeira (Dec 06 2017 at 11:03):

i mean all of this is WIP.

Jose Costa Teixeira (Dec 06 2017 at 11:03):

give me an example and I will describe how it works

Jose Costa Teixeira (Dec 06 2017 at 11:07):

for medication in 2 classes: in a Catalog you can simply add those 2 classes. But depends on the context what you want to do with those.

Jose Costa Teixeira (Dec 06 2017 at 11:07):

it depends on what you are trying to achieve.

Jose Costa Teixeira (Dec 06 2017 at 11:08):

if you give an example it is easier. Otherwise it is unclear what is the goal, and we have different discussion threads but we won't resolve any of them.

Pranitha Sruthi (Dec 06 2017 at 11:08):

As per our use case, I need an element in the Medication resource which can refer to multiple code systems. How can I do that? How can I refer a single element to multiple coding systems in a Medication profile?

Jose Costa Teixeira (Dec 06 2017 at 11:09):

what are you trying to say? that "this medication has this RxNorm code, and this GS1 code, and this SNOMED code"?

Jose Costa Teixeira (Dec 06 2017 at 11:13):

and it would really help if you bring up one example of a drug, or one example of a use case.

Pranitha Sruthi (Dec 06 2017 at 11:26):

I need to create a profile using Medication. I have to refer an element to multiple coding systems namely RxNorm, NDC,NDF-RT etc. How can I do that?

Jose Costa Teixeira (Dec 06 2017 at 11:30):

I really can't see what problem you are trying to solve. What is the profile for? Why "using Medication"? and what is "refer to multiple coding systems?"

Jose Costa Teixeira (Dec 06 2017 at 11:32):

Sorry, i am trying to help, by showing that the problem of grouping/classifying medication is not a simple one, and depends on what you are trying to achieve, so it would help if you please share an example.

Lloyd McKenzie (Dec 06 2017 at 17:58):

Medication is identified by Medication.code which is a CodeableConcept. CodeableConcept supports multiple Coding repetitions. You can send as many codes for the medication with as many code systems and as many levels of granularity as you might wish.

Brett Esler (Dec 10 2017 at 11:57):

Australian base profiles are heading the way @Lloyd McKenzie has described; we are looking at describing some of the common ways Australians code medications in our base profiles; including GTIN (GS1) and local Australian Medicines Terminology (SNOMED-CT AU) at multiple granularity levels - http://build.fhir.org/ig/hl7au/au-fhir-base/StructureDefinition-au-medication.html - work in progress

Jose Costa Teixeira (Dec 10 2017 at 13:35):

@Brett Esler I assume each of the concepts ( e.g.
- paracetamol;
- paracetamol 500 mg;
- paracetamol 500 mg tablets;
- doliprane 500;
- doliprane 500 box of 20)
will be associated with a medicationResource, with one code for each of the concepts, right?

Jose Costa Teixeira (Dec 10 2017 at 13:36):

then you may (or not) need to describe the relations, so that when you are prescribing one thing, you know you can dispense another. will you have that?

Jose Costa Teixeira (Dec 10 2017 at 13:39):

if so, then i think today we can do this with a codeset and a conceptmap

Jose Costa Teixeira (Dec 10 2017 at 13:41):

however, in some cases you may need to assign additional characteristics like classifications, other attributes.
this is why we are looking at the Catalog + EntryDefinition.

Jose Costa Teixeira (Dec 10 2017 at 13:42):

if you want, you can see entryDefinition as a straw man or a scaffold, but it has shown us that we need a kind of a pattern when we define things besides when we simply mention them in an order.

Jose Costa Teixeira (Dec 10 2017 at 13:43):

Also, we are looking at BRR's upcoming medication definitional resources.

Jose Costa Teixeira (Dec 10 2017 at 13:43):

hopefully all these things play well together.

Lloyd McKenzie (Dec 10 2017 at 16:30):

@Jose Costa Teixeira, there certainly is a need to definitionally define the hierarchy of medication concepts. This won't be done using Catalog or ConceptMap, but rather the new resource that Pharmacy and BR&R are working on that describes medication definitions. Only that will allow the proper representation of strengths, manufacturer, formulation, packaging and other aspects that the different levels of coding bring into play. However, that's not the use-case being conveyed here. There are times where when you're recording a part of the patient's medical record that you want to capture multiple levels of granularity and/or codes from multiple code systems as part of the patient record (not as definitional information). This is typically because different downstream systems - claims, decision support, etc. - need different codes and those systems don't have access to the definitional information to perform the code translation themselves. In such a case, multiple codings will be sent as translations within the CodeableConcept. Typically these translations will be handled by the source system automatically translating the selected code into the needed alternative code systems/granularities. However, in some cases the user might be involved in picking the appropriate code from each system. (This latter approach has a higher likelihood of inconsistent codes accidentally being selected.)

Brett Esler (Dec 10 2017 at 19:30):

@Dion McMurtrie might be interested in this discussion - he is looking at FHIR medication concepts hierarchies for the Australian Medicines Terminology (AMT).
@Jose Costa Teixeira we are looking to support a platform for prescribing and dispensing to allow one or more of the codings seen commonly; this includes proprietary, common drug databases, nominated national terminology, procurement, and possibly national subsidy coding. i.e. for us here that means MIMS, AMT, GTIN, PBS. We also are looking at multiple granularities using the AMT like you paracetamol list we have types Medicinal Product Pack, Trade Product Pack, Medicinal Product, Containered Trade Product etc. We may have more that one level e.g. TPP + MPP for pack level prescribing, this mainly applies to AMT in our case. To represent the codes for STU3 we use repeating Medication.code.coding for this and are looking at an extension on Coding to supply a coded 'Medication Type' to identify the granularity level for systems/cases that don't have terminology services to distinguish the type of coding (i.e. multiple AMT codes are all in the http://snomed.info/sct Coding.system and could not distinguish granularity level without terminology services) - any other approaches than extension? We really just want to identify a refset that the coding is drawn from within the drug terminology...

Jose Costa Teixeira (Dec 10 2017 at 22:17):

@Lloyd McKenzie I agree that sometimes you may want to provide several levels of granularity, other times you don't - that is ok, and of course you can say "this drug is Doliprane, but you may want to know this is Paracetamol". Sometimes you may not write any codes at all. From the requirements I am aware of, the way to define the hierarchy should be flexible and context-specific, and I don't think medication has a way to do this. I can bring forth some requirements for medication identification, but i observe they are being met with a combination of the work on Catalog, BRR and Medication, so i trust things are moving in the right direction. BRR is working on IDMP resources, and when we work with IDMP we need to combine the IDMP standard model with the different concepts existing out there. Medication is finally rid of an attibute called "isBrand" and is a flatter structure, which allows specifying or defining different concepts. and Catalog allows linking dependencies - of course we can put them in a medicationKnowledge resource, but from my experience with catalogs, this will be plagued with extensions or be a SPL-like mechanism.

Jose Costa Teixeira (Dec 10 2017 at 22:32):

@Dion McMurtrie @Brett Esler i have requested to replace medication.isBrand" with medication.conceptType - i do not know if this was followed through, or if it is considered to be in code.system. Technically I am ok with both, but if I look at e.g. SNOMED, it would be much better to have a "conceptType", for the reasons you mention. Could be medication.conceptType, or medication.code.conceptType - i hadn't thought of the latter, but i don't see why not.
Also, I am looking at this from a perspective where there are many concepts, and they have a polyhierarchical relationship. And there is always one more concept, or clusters...
This is why we are procuring a Catalog that is a graph, because the information and relations evolve over time, because of new findings, regulations, best practices, procurement agreements, distribution rules..

Jose Costa Teixeira (Dec 10 2017 at 22:35):

So, I agree we can use several codes on a medication - but that is just providing additional information and does not define the medication. You cannot risk prescribing dafalgan and charging for doliprane just because they are both Paracetamol.

Jose Costa Teixeira (Dec 10 2017 at 22:39):

If you just want to explain "what kind of a product or concept this is", indeed you just need a ConceptType to look in the local, national, international lists they may have, from substance identification like GINAS to GS1's GTIN.

Jose Costa Teixeira (Dec 10 2017 at 22:41):

I hope my arguments don't come up as abstract or complicated. I just have to deal with "scanning a GS1 code and check for equivalents or feed this to the summary or register an adverse event", and this very practical concern is facing many local simplifications.

Jose Costa Teixeira (Dec 10 2017 at 22:45):

btw, Gforge 13149 deferred to 13295, and 13295 was approved but I don't see the change . @Jean Duteau @John Hatem - shouldn't medication have a ConceptType as discussed?

Lloyd McKenzie (Dec 11 2017 at 02:33):

I suspect if several codes are sent, they'd likely be sent on the MedicationRequest/MedicationStatement/MedicationDispense/MedicationAdministration, not the Medication. You use Medication if you need to specify additional details like ingredients, lot number, etc. at which point sending multiple codes tends to make less sense.

Brett Esler (Dec 11 2017 at 02:43):

@Lloyd McKenzie thanks that makes a lot of sense... medication[x] choice is problematic when I want to include form and strength in structured elements as will lead back to using Medication rather than code alone... but will now be thinking about whether I really need that....

Dion McMurtrie (Dec 11 2017 at 04:33):

@Jose Costa Teixeira @Brett Esler I actually requested a change to medication.isBrand too, but I requested a "brand" CodeableConcept be added so that if I know the brand name text, or even the code of the brand and its display name it can be added. That can be found at https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13536&start=0

The medication.conceptType is useful to know what granularity/level the medication resource instance is representing. The presence/absence of populated elements isn't a good way to determine what level of thing the Medication resource represents. I've added an extension in my AMT Medication resource service which is an extension of the Medication resource itself, but having spoken to @Brett Esler last week it sounds like it would be better moved to medication.code.conceptType. I'm yet to prototype that to reconfirm my understanding with @Brett Esler

Examples of what I've done can be found at https://medserve.online where there's a Postman collection showing some example, and now a browser built on top of it. I'll try and get the examples changed to medication.code.conceptType using extensions and comment back when I've done that.

Dion McMurtrie (Dec 11 2017 at 05:08):

On the multiple codes for a Medication resource, it does get really confusing (at least for me) when a Medication resource has multiple codings - what does the Medication resource actually mean keeping in mind that these codings (translations really) are likely at different levels of granularity and therefore meaning.

So I've been inclined in the work that I've done transforming AMT into a catalogue of Medication resources (see https://medserve.online) I've tried to stick to just the AMT code the Medication resource is representing. Other codes like our PBS subsidy codes or ARTG regulatory codes I've tried to push out.

For the PBS code I've tried to push that out to a "subsidy" extension, which from a catalogue perspective a Medication can have 0 or more subsidies applicable under different rules in different jurisdictions. Similarly for the regulators code (ARTG in Australia) I'm working on a "regulation" extension to land that code in along with the data from the regulator relevant to that licence. In both cases I don't believe the PBS code and ARTG codes are actually medication identifiers - one identifies a subsidy and the rules under which it is valid, the other represents a licence to market and sell a medication in a jurisdiction. They can be used as proxies for identifying a medication, but they aren't really medication codes like AMT or MIMS in Australia or RxNorm in the US.

But @Brett Esler you put a good case last week where multiple codings were needed in Medication resource instances, some even from the same code system. Do you still feel this is the case? My inclination in this case is to add something to them to indicate how synonymous they are (or are being asserted to be in this context of use) to the "primary" code for the resource.

Brett Esler (Dec 11 2017 at 05:41):

okay this is where i'm coming from

• MedicationRequest, MedicationDispense, MedicationStatement all have 1..1 medicaiton[x] choice of CodeableConcept or Reference(Medication)

Brett Esler (Dec 11 2017 at 05:42):

• if I want structured forms and strength elements i'm going to use Reference(Medication)

Brett Esler (Dec 11 2017 at 05:42):

and I do

Brett Esler (Dec 11 2017 at 05:44):

• my drug data source is flat - with a primary code (proprietary) to be selected and mappings to some others (AMT TPP+MPP,, MIMS, GTIN, PBS (in this context))

Brett Esler (Dec 11 2017 at 05:45):

all of these codings have some use for receiving systems

Brett Esler (Dec 11 2017 at 05:48):

• not all systems have capability to determine a related concept from one code e.g. MPP from TPP

Brett Esler (Dec 11 2017 at 06:01):

• would say for drug data like medserve.online could still use this model - you would have profiles that relate a coding granularity to other elements of the Medication resource being present e.g. package details only make sense for CTPP (BPGC), TPP (BPG) and MPP (UPG); form details for BPGC, BPG, BPDSF, BPDF, UPDF, UPDSF, UPG

Brett Esler (Dec 11 2017 at 06:01):

using these types http://build.fhir.org/ig/hl7au/au-fhir-base/ValueSet-medication-type.html

Brett Esler (Dec 11 2017 at 06:07):

for drug data sources could make it only one granularity level per Medication resource - up to your usecase

Brett Esler (Dec 11 2017 at 06:10):

I also have some drug data sources that want to provide 2 levels only - pack and product - Medication resource representation (not all the possible levels)

Brett Esler (Dec 11 2017 at 06:13):

as for PBS code - we definitely need a place to put the definition of that subsidy; the discussion of PBS as a medicine coding (without context) basically freaked me out... I guess if it happens we'll need to deal with it... in draft http://build.fhir.org/ig/hl7au/au-fhir-base/StructureDefinition-au-medication.html I just added some words Medication PBS coding (ignore item context)

Brett Esler (Dec 11 2017 at 06:18):

for the subsidy - we will need some sort of description of eligibility statement including the PBS code, schedule, prescriber roles and other conditions... anyone have a resource type for that?

Brett Esler (Dec 11 2017 at 06:29):

also think it is worthwhile looking at where to put PBS code in the MedicationRequest, and MedicationDispense instance - i.e. subsidy for this prescribing event - this seems like an Claim or ExplanationOfBenefit

Jose Costa Teixeira (Dec 11 2017 at 08:20):

@Dion McMurtrie the "brand" concept, if I understand well, would work well for defining a product - "there's dafalgan (brand), and it is a paracetamol"

Jose Costa Teixeira (Dec 11 2017 at 08:25):

i think it would hold partially for specifying - you can also say "i prescribe dafalgan, but be informed this is paracetamol, in case you want to do grouping or substitution" - this kind of holds, but with pitfalls.

Jose Costa Teixeira (Dec 11 2017 at 08:27):

I think your "subsidy" seems another "group" of drugs. in some european countries, there is a code that represents "all paracetamol 500 mg boxes of 20 tablets, regadless of the brand". That code is defined by the national authoity, and is used for reimbursement / fraud prevention reasons.

Jose Costa Teixeira (Dec 11 2017 at 08:28):

We also have ad-hoc clusters of medication - medications that share a common code but there is not really a set of common characteristics. They are clustered in one group because someone decided so.

Jose Costa Teixeira (Dec 11 2017 at 08:45):

In both cases I don't believe the PBS code and ARTG codes are actually medication identifiers - one identifies a subsidy and the rules under which it is valid, the other represents a licence to market and sell a medication in a jurisdiction. They can be used as proxies for identifying a medication, but they aren't really medication codes like AMT or MIMS in Australia or RxNorm in the US.

Agree!

Jose Costa Teixeira (Dec 11 2017 at 08:50):

My inclination in this case is to add something to them to indicate how synonymous they are (or are being asserted to be in this context of use) to the "primary" code for the resource.

Yes, and that is what we were looking at from our Catalog profile! :) especially because of the "in this context of use". So agree with the notion, and I don't know why it should be in the medication resource or how a medication definitional would fix that.

Jose Costa Teixeira (Dec 11 2017 at 09:08):

re-posting: This is my idea for a catalog. Each of these boxes is a resource, with its own attributes.
pasted image

Jose Costa Teixeira (Dec 11 2017 at 09:10):

Suggestion: Should we have a session around this topic during our next WGM? I have a feeling of "i've felt this wall against my forehead before"...

Dion McMurtrie (Dec 11 2017 at 09:47):

Yes @Jose Costa Teixeira , check out https://medserve.online/fhir/Medication?brand=http://snomed.info/sct|26151000036107 as an example of searching by coded brand

or https://medserve.online/fhir/Medication?brand:text=panadol&brand:text=sinus as an example of searching for brand by text (all brands containing "sinus")

As an example the extension I'm using from one of these results looks like this

{
  "url": "http://medserve.online/fhir/StructureDefinition/brand",
  "valueCodeableConcept": {
    "coding": [
      {
        "system": "http://snomed.info/sct",
        "code": "29451000168102",
        "display": "Panadol Allergy Sinus"
      }
    ]
  }
}

which is saying that the Medication resource https://medserve.online/fhir/Medication/54036011000036109 which is "Panadol Allergy Sinus film-coated tablet" is from the brand "Panadol Allergy Sinus" which has the AMT code 29451000168102

Dion McMurtrie (Dec 11 2017 at 10:01):

I think your "subsidy" seems another "group" of drugs. in some european countries, there is a code that represents "all paracetamol 500 mg boxes of 20 tablets, regadless of the brand". That code is defined by the national authoity, and is used for reimbursement / fraud prevention reasons.

So, AMT has only 2 types of codes that are real tangible things - the TPUU which is a branded unitary product like "Panadol 500mg tablet" and CTPP which is a branded pack of one or more unitary products or other packages, like "Panadol 500mg tablet, 24, blister pack". The other "levels" in AMT (of which there are 4) are abstract concepts which subsume one or more of these more tangible things. That allows us to represent "Panadol 500mg tablet, 24" which subsumes all the various 24 packs (bottles, blister packs etc), or "paracetamol 500mg tablet" which would subsume all the different branded versions of that tablet - take a look at https://browse.medserve.online/Medication/23628011000036109 which shows there's 311 of them!

For package products the subsidy is sometimes expressed at the "Panadol 500mg tablet, 24" level, i.e. the government doesn't care which type of pack you supply the subsidy is the same for that brand and quantity. Mostly the subsidy code is the same for all the different brands at that level, but sometimes not.

The point is generating these Medication resources from AMT, I'm generating both abstract things and tangible things, but sometimes someone wants to say one or the other. My real aim to this was to provide an API to access the content and definitions of AMT concepts in an easier way to process.

Dion McMurtrie (Dec 11 2017 at 10:08):

My inclination in this case is to add something to them to indicate how synonymous they are (or are being asserted to be in this context of use) to the "primary" code for the resource.

Yes, and that is what we were looking at from our Catalog profile! :) especially because of the "in this context of use". So agree with the notion, and I don't know why it should be in the medication resource or how a medication definitional would fix that.

This one is interesting...coming from generating these resources to render out AMT I more or less viewed it as one code belonged in the coding - the AMT code which this Medication resource represents. I was swayed more by @Brett Esler wanting a use which was representing a Medication from an existing system's record of a patient, and it had a number of codes tagged against that record, which had intersecting but not equal meaning.

For my use case I'm not likely to want to provide translations as alternative codings on the Medication resource...but if I did (for example Brett's case) I'd want to indicate (if I knew from the system) how synonymous these other codes are to the "primary" code which carries the real meaning of the Medication resource. Something like the values from https://www.hl7.org/fhir/valueset-concept-map-equivalence.html

I think @Grahame Grieve had said that there wasn't a need because the receiving system would interpret the codes it understood and have maps to understand how the codes relate. I guess I was hoping to capture what the sending system thought about the relationship between these codes and the Medication's meaning which may be different to my understanding as the receiving system with a map. That difference is all about the context of use of those codes, which only the sending system really knows...or maybe not!

Dion McMurtrie (Dec 11 2017 at 10:13):

re-posting: This is my idea for a catalog. Each of these boxes is a resource, with its own attributes.
pasted image

That's really interesting...if you take a look at https://browse.medserve.online you'll see something very similar to your diagram happening, but rendering out how this occurs in AMT. For example look at https://browse.medserve.online/Medication/52702011000036107 although you'll have to navigate around a bit to see the full graph on your diagram. Each box in the browser is a Medication resource representing an AMT concept which deals with the abstraction levels in your diagram and a few more - 6 levels in all.

Dion McMurtrie (Dec 11 2017 at 10:15):

Suggestion: Should we have a session around this topic during our next WGM? I have a feeling of "i've felt this wall against my forehead before"...

Absolutely! I find it hard to describe this in text and probably much easier to talk over. I can probably better explain the levels of abstraction going on here and what it is I'm trying to do more clearly, even talk through some examples which is always useful. When would you like to talk it over?

Lloyd McKenzie (Dec 11 2017 at 15:47):

@Brett Esler In your use-case, I think it's fine to send multiple codings in Medication.code

Dion McMurtrie (Dec 13 2017 at 06:37):

Suggestion: Should we have a session around this topic during our next WGM? I have a feeling of "i've felt this wall against my forehead before"...

Absolutely! I find it hard to describe this in text and probably much easier to talk over. I can probably better explain the levels of abstraction going on here and what it is I'm trying to do more clearly, even talk through some examples which is always useful. When would you like to talk it over?

@Jose Costa Teixeira by the WGM do you mean New Orleans in January or a teleconference?

Jose Costa Teixeira (Dec 13 2017 at 07:22):

I meant New Orleans - in my experience this may be a change of perspective in some aspects, so it will be easier to do face to face. We can (should?) prepare in a teleconference.

Dion McMurtrie (Dec 14 2017 at 21:09):

Unfortunately I don't yet know if I'll get approval to travel for the WGM, but at the moment I think it unlikely. It would be great to talk this over face to face, it is always so much easier.
Failing that I'd be happy to do web conferences, even if I can call in to the WGM whatever the timezone implications I'd be happy to do that.

Melva Peters (Dec 27 2017 at 19:22):

I would strongly encourage everyone on this thread to help pharmacy work through the requirements. We've made some changes to the medication resource but we need your help to make sure we understand your use cases. We have an active project to look at the requirements for a potential new resource that we have tentatively called "MedicationKnowledge" and will be working with the BR&R work group to help define. Participation our our teleconference would be great too if you can't attend the WGM in New Orleans - we'd love to hear your requirements rather than trying to interpret a GForge tracker item.

Jose Costa Teixeira (Dec 28 2017 at 09:19):

Hi @Melva Peters the notions we have above are about definition of a product (Catalog), so it would be great to extend that joint discussion to Pharmacy, to expose the requirements.

Jose Costa Teixeira (Dec 28 2017 at 09:24):

besides Defining a product, there is the notion of specifying a product like
"here's a prescription for Tylenol, but be informed this is Paracetamol in case you need to know it"
(i think this is what @Lloyd McKenzie is referring to), and in that case, yes, for example that is exactly what the Dutch do:

<prescribedMedication>
<MedicationKind>
<code code="30597" codeSystem="2.16.840.1.113883.2.4.4.10" displayName="CHLOORAMFENICOL OOGZALF 10MG/G TUBE 5G" codeSystemName="G-Standaard PRK">
<translation code="15822" codeSystem="2.16.840.1.113883.2.4.4.1" displayName="CHLOORAMFENICOL OOGZALF 10MG/G"
codeSystemName="G-Standaard GPK" />
</code>
</MedicationKind>

Jose Costa Teixeira (Dec 28 2017 at 09:29):

I think Lloyd's suggestion is valid: are the codes in medication itself or in the Prescription / administration...?
In the example above, we put the different identifiers in the medication itself (which means "this medication, in this context, is defined by these two codes"). Is that the right way?

Lloyd McKenzie (Dec 28 2017 at 14:29):

It's completely legitimate to send multiple codings using different code systems that may identify the concept at different levels of granularity - so what you're doing is totally legal. The work group is exploring whether there's a more formal way of specifying this, such that the code for the manufactured drug would go in one place, the code for the generic formulation would go in another place, etc. That way the receiver wouldn't necessarily have to recognize the code system to understand what level of specificity a given code was conveying - and we'd also have consistency with when we're trying to expose the same sort of information from a knowledge-base source.

Jose Costa Teixeira (Dec 28 2017 at 14:33):

Right, just a precision from the adjacent discussion so that we move forward
"the code for the manufactured drug would go in one place, the code for the generic formulation would go in another place"
should read
"the code for one concept or granularity would go in one place, the code for another concept or granularity would go in another place"

Jose Costa Teixeira (Dec 28 2017 at 14:35):

right?
i mean the a notion of "manufactured product" and "generic formulation" is not that clear, unambiguous or universal.

Jose Costa Teixeira (Dec 28 2017 at 14:37):

(I just trying that we don't go back to medication.isBrand...)

Jose Costa Teixeira (Dec 28 2017 at 14:38):

the requirements were exposed to Pharmacy some time ago, and they are more clear now in the Catalog discussions. @Melva Peters the changes suggested to Pharmacy implement the requirements. Glad to expose more requirements if that is useful.

Last updated: Apr 12 2022 at 19:14 UTC