This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Common Product Model"

From HL7Wiki
Jump to navigation Jump to search
 
(31 intermediate revisions by 4 users not shown)
Line 32: Line 32:
 
== Governance ==
 
== Governance ==
  
−
Draft [[CPM Governance]]
+
[[CPM Governance]] as adopted during the San Diego WGM Sept 2011
  
−
== Current CPM Technical Corrections ==
+
The SVN repository is at http://gforge.hl7.org/svn/hl7v3/trunk/cpm
−
Here is a list of issues that require technical corrections to the CPM. Each point is followed by the proposed correction.
 
  
−
=== R_ProductListed (POCP_RM010100UV) ===
+
== CPM Technical Corrections ==
−
'''New Items'''
 
−
*
 
−
'''From the ISO FDIS for 11615'''
 
  
−
''For "Marketing Authorisation" and "Manufacturing Information"''
+
Details of Current Technical Corrections and Archived Technical Corrections can be found on separate pages by clicking on the links below.
  
−
In A_ProductInformation
+
[[Current Technical Corrections]]
  
−
1) Facility to indicate the country(ies) that a given marketing authorisation is valid in.  This is not the same as the territory that scopes the agency that oversees the marketing authorisation.
+
[[Archived CPM Technical Corrections]]
  
−
:QUESTION: Can you please give a use case? We have some of this already, just to make sure now we can use the same structure perhaps or what really is the issue? [[User:Gschadow|Gunther]] 22:12, 11 September 2011 (UTC)
+
[[Deprecating Lot Number Text]]
  
−
2) Facility to use an additional relationship between a CONTRACT act (the Approval) and a Marketing act to be able to describe the local marketing information that accompanies an approval - possibly a "PERT", please?
+
[[Storage Conditions and Shelf Life]]
  
−
:OK: We would agree to add an ActRelationship from MarketingAct to Approval meaning that this MarketingAct is happening with the specified Approval. It might be PERT or a better relationship type. [[User:Gschadow|Gunther]] 14:35, 13 September 2011 (EDT)
+
== Meeting Minutes ==
 +
===June 7, 2012===
 +
Attendees: Hugh Glover, Julie James, Keith Thomas, Erin Fitzsimmons, Hans Buitendijk, Gunther Schadow
 +
*
 +
===March 22, 2012===
 +
Attendees: Julie James, Keith Thomas, Hans Buitendijk, Gunther Schadow
 +
* Gunther distributed Substance Mapping spreadsheet on 2.3.A, but unclear current state.  Julie/Hugh submitted 6.1.5 mapping but had not heard until earlier this week.
 +
** At this time, everybody hoping the way it works.
 +
** Anticipate ICH may start a set of testing.  Based on that will get better feedback.
 +
* Lot Number Text
 +
** Enough support to remove from model, and then deprecate from RIM in next harmonization.
  
−
3) A confidentiality code on the role coming from the Holder participation, to be able to describe the confidentiality of the information about the marketing authorisation holder.
+
===March 8, 2012===
 +
Attendees: Julie James, Keith Thomas, Norman Gregory, Gunther Schadow, Rob Savage, Hans Buitendijk
 +
*[[Storage Conditions and Shelf Life]]
 +
**eStability focuses on new products and their storage conditions
 +
**eStability does not have shelf life, only expirationTime.  Would not use shelf live. 
 +
**The Storage act contains the storage conditions as observations.
 +
**Motion to include eStability Storage and StorageCondition into CPM model.  Change class code to Storage instead of Act on Storage and change mood code to Definition on Storage.  Would need to create a future harmonization proposal for a domains space on code in StorageCondition.  It will be put in the Product Information choice box. Gunther Schadow, Norman Gregory.
 +
***Against: 0; Abstain: 0; In favor: 3
 +
**With addition of this to CPM there is a potential to deprecate existence time, but no rush.  So for now will leave it as is.
 +
*[[Deprecating Lot Number Text]]
 +
**Julie's Questions related to Tom's comment: "sending a batch or lot ID would work by adding a 'part of' participation to a parent 'manufactured material' class, since the ID is *not* an instance identifier of the medicine (or other product) instance, but of the batch or lot that it was a part of".
 +
***No one has picked up on this?
 +
***Is it right that there are two alternative approaches?
 +
**Lots are a product instance.
 +
**Ingredients used for mixed lots, while part is used for combinations such as kits.
 +
**Looks like we have what we need and moving towards concensus.
  
−
:OK: This is easy to do, let's do it. [[User:Gschadow|Gunther]] 22:12, 11 September 2011 (UTC)
+
===February 23, 2012===
 +
Attendees: Gunther Schadow, Keith Thomas, Hans Buitendijk, Julie James, Myron Finseth, Hugh Glover
 +
*Harmonization Proposals
 +
**Reconstitution Procedure - CPM24
 +
***[[File:HL7 Harmonization Proposal Reconstitution Procedure CPM24.doc]]
 +
***There is a variance between Gunther's original vs. the snippet in the proposal.
 +
***Concerned that there will be a possible ripple effect to other areas where Act is used in general, but not a concern here.
 +
***Motion to accept as proposed. Keith Thomas, Myron Finseth
 +
****Against: 0; Abstain: 0; In Favor: 5
 +
**Disease Qualifier - CPM25
 +
***[[File:HL7 Harmonization Proposal Disease Qualifier CPM25.doc]]
 +
***Where does it live in the model? In the clinical area with contraindications, indications, severity, frequency, etc.
 +
***There is another approach possibly using Coded Data type (CD) with qualifiers.
 +
***Problem is that pre-coordination is not available in MedDRA.
 +
***Although there is concern that this proposal will not solve the real problem.  It may have to be resolved back in the FDIS.
 +
***Concept domain does not impact the model.
 +
***FDIS is in ballot, so cannot change this type of issue anymore given ISO ballot process only allows minor changes at this stage.
 +
***What happened to the CD Qualifier?  Would have to be coordinated with the terminology.  Suggestion was that post-coordination was to be done through implementation guidance.
 +
***No need to change the model to accommodate CD Data Type qualifier.
 +
***Motion to accept the proposal as is.  Julie James, Gunther Schadow.
 +
****Should not result in and create a separate class in the CPM model to accommodate. 
 +
****Suggestion to include: Terms would only be used with in post coordination within an existing CD.  Concern that is too complex.
 +
****Gunther wants the proposal as-is.
 +
****Against: 0; Abstain: 0; In favor: 5
 +
**Storage & Shelf Live - CPM26
 +
***[[File:HL7 Harmonisation Proposal Storage and Shelf Life CPM26.doc]]
 +
***e-Stability addressed this area, but did not get included in CPM.
 +
***Julie will reach out to Norman Gregory and RCRIM to get input into this proposal with goal to conclude during next week's call.
  
−
4) A Contact Party role and an SDLOC role on the Agency entity, to support the description of any contact parties within the MRA and any alternative locations (for offices of) the MRA.  This would be re-used for the Approval information that is associated with the various manufacturing operations that need describing as well (see below).
+
===February 16, 2012===
−
 
+
Attendees: Hugh Glover, Gunther Schadow, Myron Finseth, Keith Thomas, Hans Buitendijk, Rob Savage
−
:4.1 - OK: Agency contact party could make sense. [[User:Gschadow|Gunther]]
+
*Agenda:
−
 
+
** How to tie IDMP back to CPM
−
:4.2 - QUESTION: can you give use case scenario for this SDLOC thing? [[User:Gschadow|Gunther]]
+
** Harmonization Proposals (9 total - 3 a week)
−
::more discussion has happened ... one obvious thing to do is to make the dummy-role on the holder participation a real role with scoper and player. It could point to the AssignedEntity role (e.g. POCP_RM303000)
+
** Technical Corrections
−
 
+
*IDMP to CPM
−
In E_ProductEstablishment
+
** So far we grew CPM to cover IDMP, but is becoming unwieldy.
−
 
+
** Primary objection/concerns that if you unroll CPM people get schemas that are new to them.
−
1) We need SDLOC on the Organisation entity, to describe any alternative locations (for offices of) the organisation - primarily to be used when describing various manufacturing scenarios
+
** Present CPM with CMETs, but include guidance on where things for IDMP, how to thread it together, serialization.
−
 
+
** Should that information in CPM or IDMP implementation documentation? Should be in IDMP documentation.
−
:COMMENT: we already have any level of sub-organization which is used today for multiple establishments, representing offices, importers, why is that not enough and how would you differentiate when to use which role? [[User:Gschadow|Gunther]] 13:23, 12 September 2011 (UTC)
+
** We're reviewing it here as there will be adjustments likely.
−
 
+
** IDMP is on same May Ballot Cycle.
−
2) We need a role.code on the Contact Party role, to describe the role of the person in the organisation (be that for the marketing authorisation holder organisation or the manufacturing organisation).  This will also allow description of QPPV etc.
+
* Harmonization Proposals
−
 
+
** Combined Dose Form Concept Domain - CPM-21
−
:OK: Very true, I already use these attributes internally in implementation for exactly the same purpose, so yes. [[User:Gschadow|Gunther]] 22:12, 11 September 2011 (UTC)
+
*** [[File:Combined Dose Form.doc]]
−
 
+
*** Motion to accept as proposed. Hugh Glover, Rob Savage Against: 0; Abstain: 0; In Favor: 4
−
3) The various manufacturing processes can be described using the ActDefinition in E_ProductEstablishment, but there appears to be no way to describe the formal authorisation and authorisation agency for these processes.  Having a relationship to an Approval (contract) act, with its associated author/TA/Agency (plus Contact Party and SDLOC requested above) would meet that requirement.
+
** Material Form - CPM-22
−
 
+
*** [[File:Material Form.doc]]
−
:COMMENT: Interesting, so in the scope of use-cases is facility approval, facility inspection and those issues? Here we have this only implemented for facility registration, i.e., a unilateral declaration of manufacturers of their activity. I don't think that each activity requires approval, for instance, an importer would not require agency approval. Also many facility are fulfilling more than one activity. I think some real use case scenarios would be needed to ensure whatever we add here will be what is really needed (and will really be used). [[User:Gschadow|Gunther]] 13:23, 12 September 2011 (UTC)
+
*** Concern that this cannot be put above Material.  A Combined Dose Form could consist of multiple materials of different forms.
−
 
+
*** Suggest to carry into OO discussion in next 2 weeks.
−
For the Clinical Particulars Section
+
** Container Form Concept Definition - CPM-23
−
 
+
*** [[File:Container Form.doc]]
−
The clinical information described in the ISO FDIS for 11615 is, I think, a little more structured (and codified) than that in SPL, but nevertheless we have found that the structures in A_ProductGuidelines(SPL) are able to accommodate pretty much all of the requirements, which has been very pleasing.  Inevitably though, there are just a couple of things......
+
*** Motion to accept as is. Gunther Schadow, Hugh Glover. Against: 0; Abstain: 0; In Favor: 4
−
 
+
*RIM Proposals
−
:COMMENT: (Thanks, may be you want to consider that next time in the Pharmacy Committee as well? [[User:Gschadow|Gunther]])
+
**Contaminant is an Ingredient
−
 
+
***[[File:RoleClass Contaminant is an Ingredient.doc]]
−
1) Having the .text attribute added to the SubstanceAdministration1 act would be very helpful, though.  Each clinical particualr (be it an indication, CI, DI etc.) has its full text statement as well as its coded decomposition, and it seems that the core SubstanceAdministration1 act .text attribute would be the right place to hold this.
+
***Motion to accept as is.  Gunther Schadow, ??. • Against: 0; Abstain:0; In Favor: 4
−
 
+
** Living Subject
−
:OK: No problem. [[User:Gschadow|Gunther]] 13:23, 12 September 2011 (UTC)
+
*** [[File:Living Subject.doc]]
−
 
+
*** Not yet discussed.  Next week
−
2) Much as I (Julie) am loathe to use the .code attribute on an SBADM act, I think we do have a valid use case for it - on the SubstanceAdministrationCriterion act, to describe whether the "other therapy" is second-line or adjunctive etc.
 
−
 
 
−
:COMMENT: possibly, but if we were to do this, what would be the starter terminology and how exactly would each term be defined? Doesn't second-line mean do this if the first line fails? If so, isn't this more a concept of a relationship between therapies than an absolute? Or, if you witnessed a "second-line" therapy being administered, would you notice it's "secon-line" nature? If not, this probably does not belong in the SBADM Act itself. Same comment for adjunctive. Are you looking in main SubstanceAdministration1-precondition or Issue-subject? Where I think it might best fit is Protocol if we extend Protocol component target with the choice of Acts besides Monitoring. [[User:Gschadow|Gunther]] 13:23, 12 September 2011 (UTC)
 
−
 
 
−
3) In the FDIS, indications and contra-indications share a very similar pattern - and we could model this very nicely - and therefore make the implementation easier to follow for users - if we could use the act relationship CIND - contra-indication - as a choice with RSON (reason) for indication.  We realise that this differs from the "Issue" pattern, which we use for Adverse Effects and Interactions.  This may need some further discussion.
 
−
 
 
−
:COMMENT: This is making me smile, because I too thought so way back in 1999, that's why CIND exists. I initially didn't like the Issue stuff as much (but I think you made me do it), but today I think the Issue is simple and powerful to not only say: "don't give this in that situation ..." but also "because if you do then #@*$ may occur". Contraindication and adverse reaction are really just gradual differences and with Issue they meet on an extremely useful middle ground. [[User:Gschadow|Gunther]] 13:24, 12 September 2011 (UTC)
 
−
 
 
−
4) There is a lot of use of the EVN.CRT mood, though this is deprecated.  Could we review this, please?
 
−
 
 
−
:QUESTION: What would the non-deprecated way of doing this be? There's some new attribute? Does that really matter if this is all fixed anyway? [[User:Gschadow|Gunther]] 13:24, 12 September 2011 (UTC)
 
−
 
 
−
'''Outstanding Items'''
 
−
*
 
−
'''Completed Items'''
 
−
# There are a number of Marketing Authorization Dates: First Authorization Date, Renewal Date, Variation Date, Withdrawal Date, Expiry Date.  This can be solved by providing a recursive COMP relationship from an authorization to itself.
 
−
#: DONE [[User:Gschadow|Gunther]] 16:33, 17 November 2010 (UTC)
 
−
# Each Marketing Authorization produces a GTIN.  Provide a SubjectOf shadow from IdentifiedEntity.
 
−
#:DONE [[User:Gschadow|Gunther]] 16:33, 17 November 2010 (UTC)
 
−
#IdentifiedEntity needs an effectiveTime
 
−
#:DONE [[User:Gschadow|Gunther]] 16:33, 17 November 2010 (UTC)
 
−
#SubjectOf needs a time to indicate when the relevant product information took effect
 
−
#:QUESTION: such time range would be provided by the connected Act, wouldn't it?
 
−
#::DONE: My thought was that the effectiveTime of the document could be different from the time when it was attached to the product.  But now that I look at it, I don't think that distinction makes sense. --[[User:Jduteau|Jduteau]] 23:06, 18 November 2010 (UTC)
 
−
#We need to indicate the dose form and the product classification that the marketing authorization pertains to.
 
−
#:QUESTION: that is already supported because the Approval is connected to a Role whose player Entity has a dose form and can have classifications. [[User:Gschadow|Gunther]] 00:51, 18 November 2010 (UTC)
 
−
#::CLARIFICATION: the authorization pertains to a specific form and classification.  I'm unsure which Role you are referring to as the one with ProductEstablishment doesn't let me detail this.
 
−
#:::DONE: Relates to a specific product with form, etc. all part of the product description. Now, if you say the authorization relates to a "classification" then I think you really mean "indication", or "purpose" for which the product is approved. Currently this is held together by the product document, the label, that is approved. I have added the subjectOf participation to the specializedKind role. [[User:Gschadow|Gunther]] 14:09, 29 November 2010 (UTC)
 
−
#We need to have the address of the governing agency address.
 
−
#:DONE [[User:Gschadow|Gunther]] 00:51, 18 November 2010 (UTC)
 
−
#How to tie the Marketing Authorization Procedure to the marketing authorization.
 
−
#:ANSWER: the procedure may be reflected in the Approval.code, as it is in the U.S. or you might use the new Approval components to represent these procedures and other smaller actions.
 
−
#How do we indicate the point and country where a measurement was made.
 
−
#:ANSWER: ingredient strength is connected to a product and if the strength is different, then it is a different product. The country-specificity can be done with the Approval act.
 
−
#::CLARIFICATION:  In the US there is an inhaler that is measured by dose that reaches the mouth whereas in Europe exactly the same product is measured at the point the dose leaves the spray. The values are simiilar but different so there effectivly 2 different strengths which are equivalent if you use common measurement measures.  Hence a need to express measurement point and countrry.  After rethinking this, I believe that I can map this as a characteristic of the ingredient.
 
−
#:::DONE: I agree with you, these fine details can be done with those characteristics. [[User:Gschadow|Gunther]] 14:09, 29 November 2010 (UTC)
 
−
 
 
−
=== R_Substance (POCP_RM080300UV) ===
 
−
'''New Items'''
 
−
#A substance name is a string that needs to have a language designation; it can also have 0...* "types". The Substance entity in the CPM Substance model has name as COLL<TN>; we think that as trivial name, it has lost its ability to have a language designation; suggest that using either EN or ST.NT to carry the text name and the language may be more appropriate?
 
−
 
 
−
'''Outstanding Items'''
 
−
#Need to indicate a substance that is related to a characteristic (antigen ID for cells)
 
−
#:ANSWER: this is what Interaction is for: antibody - interactsIn - Interaction[Ab-Ag-binding] - interactor - antigen
 
−
#::CLARIFICATION: antigen ID was one example - the generic use case is "Substance related to a property that is not the substance being described".  And the problem with your solution is that I have a property of the substance and this property is related to an antigen and I need to provide the antigen ID.
 
−
#:::QUESTION: this clarification does not show any additional need. Your antigen ID is supported. "Substance related to a property" -- there are many ways by which substances can relate to properties of other substances. You need to be specific on the use cases. Give all the examples that you have, likely they are modeled in a few different patterns.
 
−
#::::CLARIFICATION:
 
−
#::::#If the substance being described is a T-cell, for example, which would be classified as a “structurally diverse substance”, then the auxiliary substance would be CD4 glycoprotein which would itself have a substance ID.  So we’re not describing CD4 here as an interactant, we’re describing it as an auxiliary in the description of a property.
 
−
#::::#::You can think of the CD4 as a part of the T-cell, a moiety. But I guess (subject to further refinement of this example) you mean here the measurement of strength or quality of Sipuloeucel in terms of CD4. That is a metrological problem, where you measure one thing in terms of another. The question is what do you really need for this? If you specify the measured property as "CD4 linked flow-cytometry" or "anti-CD4 ELISA" or something like that, you do that in the Observation.code (Characteristic.code). What do you gain by referencing another code that means "CD4" somewhere in addition?
 
−
#::::#In describing a polymer, the defining property might be the degree of binding to a dye that occurs (a bit like titration) and the particular dye would be the auxiliary substance.
 
−
#::::#::Again that is just a property code "Degree of binding to X-Dye". Only if you have more than 10 or 100 variants of this does it begin to make sense to post-coordinate the property code by moving the substance out.
 
−
#::::#To describe a nanoparticle, which would be another “structurally diverse substance”, there may be a particular protein that would bind to the nanoparticle, the protein would be the auxiliary substance.
 
−
#::::#::Same issue, precoordinate this in the property code.
 
−
#::::#To describe a low molecular weight heparin (bemeparin, dalteparin, enoxaparin), which would be considered a polymer substance, the amount of binding (again a bit like titration) of Factor IIA and/or Factor X could be used as a defining property.  The Factor IIA or Factor X would be the auxiliary substances.
 
−
#::::#::Same issue, there are so many metrologic details that need to be provided to define the property that this post-coordination does not add much.
 
−
#The Moiety has a mandatory link to the played entity.  For Subunits, I have no entity to reference, so this link should not be mandatory.  I could just hang an entity since none of the attributes are mandatory, but that seems wrong.
 
−
#:ANSWER: of course you must have an Entity, the subunit itself. The subunit must be something. Typically a protein subunit is coded on a different gene, so you would even have a different protein id (say if you use UniProt). Even if by "subunit" you mean "domain", such an entity can have and should have an identification, for instance, the UniProt sub-sequences (chains) have feature identifiers.
 
−
#::REBUTTAL: Well yes I have the subunit, but I have no attributes about the subunit, i.e no ID.
 
−
#::::ANSWER: of course you have attributes about the sub-unit. You definitely will have something saying what the subunit is, e.g., kappa and lambda chains of an antibody. And as the document with example shows, you should assign a local id also, so you can refer to the subunits and describe how they are connected (e.g., by disulfide bonds).
 
−
#(Related to Completed #7) I have Glycosylation which has a number of characteristics (Type, N, O, C) and they can all repeat.  So I still feel that the ability to have a parent characteristic (Glycosylation) with children (Type, N, O, C) is needed.
 
−
#:ANSWER: still no, glycosylation type should not be a characteristic. It should be a code specified in the Moiety.code or Bond.code, see the document on page 31f (Posttranslational Modification).
 
−
#::REBUTTAL: From what I understand about Glycosylation, it is a defining type of the Protein - Human, Other mammal, Yeast, Plant, Insect - they all produce completely different substances even if everything else about the protein is the same.  So it does not belong in the Moiety.code or Bond.code as it is specific to the overall substance.
 
−
#::::ANSWER: Glycosylation is not a "defining type of a protein". It is a complex glycane (sugar-structure) that is linked at an N, O, or C atom on various amino acids. The glycane structure is a complex tree structure and usually not completely described (although some people in Glycoproteomics study the nature of these). The Glycane structure is different in different cells, so when you have recombination insulin in E. coli or Yeast, the glycane structures will be different. Of course when you change even one atom on a protein you will have a "different substance", but I don't understand the significance of "they all produce completely different substances", because without recombinant human DNA, the protein will be different. So, I don't understand what your rebuttal is saying and how it is relevant. What I said is that the glycosilation is the substitution of a glycane and that means a bond between a glycane and the protein. The Bond type will let you say things about the nature of the bond, i.e., N, O, C glycosylation is said there. Please refer to the document, it is described there with pictures.
 
−
 
 
−
'''Completed Items'''
 
−
#How to indicate the Gene and the specific Gene element that a Substance is derived from?
 
−
#:ANSWER: IdentifiedSubstance - productOf - DerivationProcess - interactor - IdentifiedSubstance [[User:Gschadow|Gunther]] 00:51, 18 November 2010 (UTC)
 
−
#::DONE --[[User:Jduteau|Jduteau]] 23:07, 18 November 2010 (UTC)
 
−
#We have a status and domain of names.
 
−
#:ANSWER: for domain: NamedEntity - subjectOf - Policy [[User:Gschadow|Gunther]] 00:51, 18 November 2010 (UTC)
 
−
#::QUESTION: for "status", what are those statuses?
 
−
#:::CLARIFICATION: current, alternate, superceded
 
−
#::::DONE: The specification of what name you need to use under what circumstances is carried by the Policy that you can associate with the Identified(Named)Entity role. If these policies are outdated, or say that you can use a name as an alternative or not any more, would all be handled by Policy. Also added statusCode and effectiveTime into NamedEntity and IdentifiedEntity roles, with a note to use Policy for fine control. [[User:Gschadow|Gunther]] 14:09, 29 November 2010 (UTC)
 
−
#How to indicate what the amount of a moiety is (mole ratio, weight percent) - this may be similar to the "Amount Type" that is present on all amounts.
 
−
#:ANSWER: the Role.quantity gives you a ratio, if you put there 1 mol : 1 mol it's a mole-ratio, if you put 1 g : 1 g it's a mass ratio.
 
−
#::DONE--[[User:Jduteau|Jduteau]] 23:07, 18 November 2010 (UTC)
 
−
#We need a "SubjectOf" relationship on the NamedEntity to indicate reference information for the names.
 
−
#:DONE [[User:Gschadow|Gunther]] 00:51, 18 November 2010 (UTC)
 
−
#Need to provide documentation of a characteristic.
 
−
#:QUESTION: use case please? Do you mean the subjectOf relationship to Document should be added?
 
−
#::CLARIFICATION: Yes, there is a need to provide the reference documentation for a characteristic value, so subjectOf relationship to Document.
 
−
#:::DONE [[User:Gschadow|Gunther]] 14:09, 29 November 2010 (UTC)
 
−
#We have processSteps that have sub-processSteps. SubstanceSpecification does not allow this.
 
−
#:DONE [[User:Gschadow|Gunther]] 00:51, 18 November 2010 (UTC)
 
−
#There needs to be a way to link characteristics to each other - either as a grouping of related characteristics or as a parent/child relationship.
 
−
#:QUESTION: It's easy to add this, but there should be at least one use case. What is it?
 
−
#::CLARIFICATION: I have a Protein Substance that has information about the sequence.  There are characteristics that are all about the sequence.  As well, each sequence has a number of sub-units and each sub-unit has a number of characteristics.  So it would be nice to tie all of the sub-unit characteristics together and I believe that it is necessary to indicate that each subunit set pertains to the sequence.
 
−
#:::ANSWER: Subunits are different Moieties. You put characteristics onto the molecular part that they pertain to, not on the higher order molecular complex. So, it is actually good that you do not have these characteristics structures, because they make you focus on modeling the molecule, not the information about it. [[User:Gschadow|Gunther]] 14:09, 29 November 2010 (UTC)
 
−
#Many codes have a status and change date of the code.
 
−
#:QUESTION: which codes? the "last change date" is a database-ism that does not really do much, in most cases you can refer to the Document that contains the change if you wanted to.
 
−
#R_SubstancePresence - the scoper is not actually attached to the choice box.
 
−
#:DONE [[User:Gschadow|Gunther]] 12:49, 3 December 2010 (UTC)
 
−
#Need to provide documentation of the derivation process - need a link to Document.
 
−
#:DONE [[User:Gschadow|Gunther]] 12:49, 3 December 2010 (UTC
 
−
 
 
−
 
 
−
'''Comments for Drug Stability Reporting:'''
 
−
 
 
−
Stability reporting has been identified as a POCP_DM010000UV stakeholder whose reporting needs were to be explored.  While attending the Fall 2010 Working Group Meeting, the stake holders of Drug Stability Reporting were not heard due to time limitations.  We are noting our exception to the model in it current form because it does not address the notion of substance as it is understood in stability testing.  The model is focus on how the product presents itself to the patient as an administered product.  This in turn makes the substance an administered substance.  This does not correlate to stability testing, where the substance (Active Pharmaceutical Ingredient) is a manufactured material, which is similar to a product.  There are, however differences between a substance and product that precludes using the Product ProductKind when dealing with substances.
 
−
 
 
−
Please refer to the Stability Study RMIM.  Notice that the message has a choice to report on a substance or a product.  Nowhere in POCP_DM010000UV is this choice available.  The choice determines the use of other elements and attributes.  Most importantly a substance will be an instance of an ingredientManufacturedMaterial with a lot number, existence time and a retest time.  We do not think you adequately model the Substance as a ManufactureMateial.
 

Latest revision as of 13:07, 7 June 2012

This page will be used to discuss the content and publication of the Common Product Model.

Ambitions & Scope

The Common Product Model (CPM) will be an overarching domain information model relating to the HL7 v3 modeling of any kind (or instance) of a 'product'. The definition of the term product is intentionally kept loose at this point, but will definitely include:

  • Medication, incl. vaccines
  • Devices used in medical services
  • Anything else a person can be exposed to

The CPM is set up as a joint initiative within HL7 project, 'sponsored' by the O&O work group.

The following stakeholders have been identified:

  • Pharmacy (for Medication and possibly for devices)
  • Patient Safety (for Individual Case Safety Reports)
  • RCRIM (for Structured Product Labeling, Regulated Product Submissions, and Drug Product Stability)
  • PHER (for vaccines used in Immunization)

Storyboards

This space will list a number of storyboards that relate to the different perspectives on what a product is and how it is used.

These storyboards are divided into groups:

Governance

CPM Governance as adopted during the San Diego WGM Sept 2011

The SVN repository is at http://gforge.hl7.org/svn/hl7v3/trunk/cpm

CPM Technical Corrections

Details of Current Technical Corrections and Archived Technical Corrections can be found on separate pages by clicking on the links below.

Current Technical Corrections

Archived CPM Technical Corrections

Deprecating Lot Number Text

Storage Conditions and Shelf Life

Meeting Minutes

June 7, 2012

Attendees: Hugh Glover, Julie James, Keith Thomas, Erin Fitzsimmons, Hans Buitendijk, Gunther Schadow

March 22, 2012

Attendees: Julie James, Keith Thomas, Hans Buitendijk, Gunther Schadow

  • Gunther distributed Substance Mapping spreadsheet on 2.3.A, but unclear current state. Julie/Hugh submitted 6.1.5 mapping but had not heard until earlier this week.
    • At this time, everybody hoping the way it works.
    • Anticipate ICH may start a set of testing. Based on that will get better feedback.
  • Lot Number Text
    • Enough support to remove from model, and then deprecate from RIM in next harmonization.

March 8, 2012

Attendees: Julie James, Keith Thomas, Norman Gregory, Gunther Schadow, Rob Savage, Hans Buitendijk

  • Storage Conditions and Shelf Life
    • eStability focuses on new products and their storage conditions
    • eStability does not have shelf life, only expirationTime. Would not use shelf live.
    • The Storage act contains the storage conditions as observations.
    • Motion to include eStability Storage and StorageCondition into CPM model. Change class code to Storage instead of Act on Storage and change mood code to Definition on Storage. Would need to create a future harmonization proposal for a domains space on code in StorageCondition. It will be put in the Product Information choice box. Gunther Schadow, Norman Gregory.
      • Against: 0; Abstain: 0; In favor: 3
    • With addition of this to CPM there is a potential to deprecate existence time, but no rush. So for now will leave it as is.
  • Deprecating Lot Number Text
    • Julie's Questions related to Tom's comment: "sending a batch or lot ID would work by adding a 'part of' participation to a parent 'manufactured material' class, since the ID is *not* an instance identifier of the medicine (or other product) instance, but of the batch or lot that it was a part of".
      • No one has picked up on this?
      • Is it right that there are two alternative approaches?
    • Lots are a product instance.
    • Ingredients used for mixed lots, while part is used for combinations such as kits.
    • Looks like we have what we need and moving towards concensus.

February 23, 2012

Attendees: Gunther Schadow, Keith Thomas, Hans Buitendijk, Julie James, Myron Finseth, Hugh Glover

  • Harmonization Proposals
    • Reconstitution Procedure - CPM24
      • File:HL7 Harmonization Proposal Reconstitution Procedure CPM24.doc
      • There is a variance between Gunther's original vs. the snippet in the proposal.
      • Concerned that there will be a possible ripple effect to other areas where Act is used in general, but not a concern here.
      • Motion to accept as proposed. Keith Thomas, Myron Finseth
        • Against: 0; Abstain: 0; In Favor: 5
    • Disease Qualifier - CPM25
      • File:HL7 Harmonization Proposal Disease Qualifier CPM25.doc
      • Where does it live in the model? In the clinical area with contraindications, indications, severity, frequency, etc.
      • There is another approach possibly using Coded Data type (CD) with qualifiers.
      • Problem is that pre-coordination is not available in MedDRA.
      • Although there is concern that this proposal will not solve the real problem. It may have to be resolved back in the FDIS.
      • Concept domain does not impact the model.
      • FDIS is in ballot, so cannot change this type of issue anymore given ISO ballot process only allows minor changes at this stage.
      • What happened to the CD Qualifier? Would have to be coordinated with the terminology. Suggestion was that post-coordination was to be done through implementation guidance.
      • No need to change the model to accommodate CD Data Type qualifier.
      • Motion to accept the proposal as is. Julie James, Gunther Schadow.
        • Should not result in and create a separate class in the CPM model to accommodate.
        • Suggestion to include: Terms would only be used with in post coordination within an existing CD. Concern that is too complex.
        • Gunther wants the proposal as-is.
        • Against: 0; Abstain: 0; In favor: 5
    • Storage & Shelf Live - CPM26

February 16, 2012

Attendees: Hugh Glover, Gunther Schadow, Myron Finseth, Keith Thomas, Hans Buitendijk, Rob Savage

  • Agenda:
    • How to tie IDMP back to CPM
    • Harmonization Proposals (9 total - 3 a week)
    • Technical Corrections
  • IDMP to CPM
    • So far we grew CPM to cover IDMP, but is becoming unwieldy.
    • Primary objection/concerns that if you unroll CPM people get schemas that are new to them.
    • Present CPM with CMETs, but include guidance on where things for IDMP, how to thread it together, serialization.
    • Should that information in CPM or IDMP implementation documentation? Should be in IDMP documentation.
    • We're reviewing it here as there will be adjustments likely.
    • IDMP is on same May Ballot Cycle.
  • Harmonization Proposals
    • Combined Dose Form Concept Domain - CPM-21
    • Material Form - CPM-22
      • File:Material Form.doc
      • Concern that this cannot be put above Material. A Combined Dose Form could consist of multiple materials of different forms.
      • Suggest to carry into OO discussion in next 2 weeks.
    • Container Form Concept Definition - CPM-23
  • RIM Proposals
Retrieved from "https://wiki.hl7.org/w/index.php?title=Common_Product_Model&oldid=62679"