Stream: BRR - Pharmacy model
Topic: Feedback on current model
Jose Costa Teixeira (Aug 14 2020 at 05:15):
I want to use some of these resources, and I want to understand them. @Rik Smithies , others(?) What is the best way to discuss?
I just found a small issue in MPDefinition.indication (should refer to ClinicalUseIssue) but this gave me more questions e.g.:
- Why do we have MPDefinition.indication as text, but ClinicalUseIssue as a separate set of resources? Is MPDefinition.indication going to contain the concatenation of all the ClinicalUseIssues.description?
Jose Costa Teixeira (Aug 14 2020 at 05:19):
- the package concept in PackagedProductDefinition and the batch identifiers seem so be similar to how IDMP states them (i.e. not the way actual systems do at least outside of regulatory). So the scope should be clear if we want to maintain that inconsistency (I presume there may be reasons to maintain it)
Jose Costa Teixeira (Aug 14 2020 at 05:23):
I'm not dumping a set of complaints - this is feedback, but I think if I put this on a chat it will seem less constructive than I mean it.
I'm looking at IDMP and the EMA's IG and I want these resources to be in good shape.
Jose Costa Teixeira (Aug 14 2020 at 05:25):
and (Because communication issues) I am not implying that any issues are blocking for having a release. It's good to expose these resources to some fresh air and fresh feedback.
Rik Smithies (Aug 14 2020 at 09:04):
MPD.indication is different from using ClinicalUseIssue. It is needed because the current generation of systems often carries this as one block of text, about all the indications. It cannot easily be separated into multiple resources, so cannot use ClinicalUseIssue, and it is not a duplication/concatenation (well it is but at source data level not at FHIR data level). ClinicalUseIssue is of course also available for use and it is not showing in MPD because it points in, not out of the resource.
Rik Smithies (Aug 14 2020 at 09:09):
Re PPD and batch, the intent is to cover all use current cases so please let us know the specific gap we are not handling.
Jose Costa Teixeira (Aug 14 2020 at 09:26):
indication ok for now (i was looking for a way to discuss, let's use this chat then) it just feels awkward, not something I can point to.
Jose Costa Teixeira (Aug 14 2020 at 09:34):
PPD and batch - well, this is a very awkward construct.
What is normally done is : you can nest items (boxes of boxes, or boxes inside boxes) and each of them has a set of production identifiers - lot, serial, expiry, etc. using only "batch" as an identifier would make sense if you want to disregard serialization, and if you want to force people to describe the expiry dates for the batch elsewhere (which would be strange). And I do not see why "outerpackaging" and "immediatepackaging" are both in batch. If a package contains another package, the nesting can take care of this.
Jose Costa Teixeira (Aug 14 2020 at 09:36):
why not a single "batch" backbone with serial, expiry, etc. as in Medication resource?
Jose Costa Teixeira (Aug 14 2020 at 09:37):
I was looking at shelf life but that is different. Shelf life is about the kind (definitional), batch is about the instance.
Rik Smithies (Aug 14 2020 at 09:38):
The identifiers I added on the package were meant to allow numbers at all levels (which is not supported in IDMP). We may be able to remove BatchIdentifier, it is true.
Jose Costa Teixeira (Aug 14 2020 at 09:38):
also, this resource is definitional.
if batch means "these were the batches produced and put in the market" - that for me would be a new resource, looking at the instance, not kind
Jose Costa Teixeira (Aug 14 2020 at 09:39):
I don't know the workflow but do manufacturers have to redeclare the product when informing that a new batch is being created? I'd hope not.
Rik Smithies (Aug 14 2020 at 09:40):
This resource can/could also be used for instances. The scope may need changing or clarifying but it has always has batch identifiers - which are only really on instances. We wouldn't want to clone the whole resource to allow instances, when they fit fine in the data items as now.
Rik Smithies (Aug 14 2020 at 09:43):
shelf life can be about an instance
Jose Costa Teixeira (Aug 14 2020 at 09:49):
shelf life can be 2 things: definitional (6 months) and instance (today + 6 months)
Jose Costa Teixeira (Aug 14 2020 at 09:52):
I understand this resource can be rescoped or the scope clarified (which makes my feedback a challenge because I do not know if I am saying something that is known and not documented). But if a thing called PackagedProductDefinition can also be used for instances, that is not how we have been doing it so far, right? And it should be very well documented because it will overlap with inventory management
Jose Costa Teixeira (Aug 14 2020 at 09:54):
Specifically on shelf life I would make it very clear the difference between the definitional aspect and the instance
Rik Smithies (Aug 14 2020 at 09:55):
The "definition" in these resources is not about instance vs kind it is about level of detail. Mostly the resources would be definitions but there is a need for some to be instances, hence batch numbers. The Medication resource can also be both an instance and a kind too.
Jose Costa Teixeira (Aug 14 2020 at 09:55):
Yes, but Medication resource is transactional data, these resources are master data
Rik Smithies (Aug 14 2020 at 09:57):
I am not sure why that makes a difference. We don't draw any distinction in FHIR. If it is used as an instance then it is "transactional" perhaps.
Jose Costa Teixeira (Aug 14 2020 at 09:57):
I don't think this is wrong. I just think that if that is the approach, it should be well documented, data segmented (like shelf life vs expiry date). And the name might be best "PackagedProduct"
Rik Smithies (Aug 14 2020 at 09:58):
re shelf life, we can make any clarifications as needed. Which applies to everything.
Jose Costa Teixeira (Aug 14 2020 at 09:58):
Rik Smithies said:
If it is used as an instance then it is "transactional" perhaps.
Agree
Jose Costa Teixeira (Aug 14 2020 at 09:58):
Rik Smithies said:
I am not sure why that makes a difference. We don't draw any distinction in FHIR.
I think we do sometimes, sometimes we don't
Jose Costa Teixeira (Aug 14 2020 at 09:59):
Rik Smithies said:
re shelf life, we can make any clarifications as needed. Which applies to everything.
Yes, separate shelf life (definition, stays where it is) and add expiry (under the batch thing)
Rik Smithies (Aug 14 2020 at 09:59):
Re the names, it was very hard to come up with a set of names that worked best, and we discussed it many many times in different forums over more than a year. So, while not ideal, I would not be keen to alter then unless there was very significant problems with them.
Jose Costa Teixeira (Aug 14 2020 at 10:00):
I know the struggle, but when you agreed on the scope of xxxDefinition, was it clear that this would also support instances? I'd expect that would raise some attention
Rik Smithies (Aug 14 2020 at 10:01):
I would have preferred PackagedProduct, and MedicinalProduct, but those names were rejected
Jose Costa Teixeira (Aug 14 2020 at 10:02):
IMO the name should match the scope
Jose Costa Teixeira (Aug 14 2020 at 10:03):
re batch - besides the discussion whether it fits into a new resource or not, IMO it does not make sense to put those two identifiers. batches of different levels should be handled with the nesting of the package that you already do
Rik Smithies (Aug 14 2020 at 10:06):
yes, I agree. but we live in a world where you cannot fully describe things in the name of a resource, which needs to be relatively short. When these were originally proposed the main summary diagram (I have posted this a few times) was this, where the relationship/purpose is something like "fully described resources-sketch.png by"
Jose Costa Teixeira (Aug 14 2020 at 10:06):
btw, is "Pharmaceutical Product" called "AdministrableProduct"?
Rik Smithies (Aug 14 2020 at 10:06):
yes
Rik Smithies (Aug 14 2020 at 10:07):
re batch I agreed with you, in principle, further up the thread
Jose Costa Teixeira (Aug 14 2020 at 10:07):
(that is a bit confusing because that is the one that is not commercialized or administered, right? isn't that at the level of VMP?)
Rik Smithies (Aug 14 2020 at 10:09):
it is what is administered
Jose Costa Teixeira (Aug 14 2020 at 10:09):
PhPs are not existing per se
Rik Smithies (Aug 14 2020 at 10:10):
sorry, I don't understand that comment
Jose Costa Teixeira (Aug 14 2020 at 10:11):
I understand the PhP as an abstraction for the products. Nobody gets paracetamol 500 mg tablets. They get Tylenol
Rik Smithies (Aug 14 2020 at 10:12):
I don't see how that relates to this. This is not about branded vs generic (or branded generics)
Jose Costa Teixeira (Aug 14 2020 at 10:15):
If the names are the best we could do but the scope is not documented, it's hard to understand the resource.
For example this AdministrableProductDefinition has a "property" which can be many things, including things that belong in other resources
Rik Smithies (Aug 14 2020 at 10:16):
sure, we would be happy to requests with clarifying text
Jose Costa Teixeira (Aug 14 2020 at 10:16):
PhP - the point is that a PhP is not an administrable product. It's an abstraction that represents perhaps the administrable form and other characteristics. But that is minor, we can move along
Rik Smithies (Aug 14 2020 at 10:17):
there is no PhP in this model, afaik
Jose Costa Teixeira (Aug 14 2020 at 10:17):
I thought PhP was now called AdministrableProduct
Rik Smithies (Aug 14 2020 at 10:17):
no
Jose Costa Teixeira (Aug 14 2020 at 10:18):
maybe I phrased it wrongly, that is what i meant by
is "Pharmaceutical Product" called "AdministrableProduct"
Jose Costa Teixeira (Aug 14 2020 at 10:21):
thanks for the information. I understand the meaning better now.
I hear that you're happy to get requests to clarify text - I expect there will be a lot of that needed for this to be clear.
And I also expect that some wrinkles may need changes.
Rik Smithies (Aug 14 2020 at 10:22):
AdministrableProductDefinition is a resource yes. It is not synonymous with a PhP (which I know as a specific term for an ID system, and which can be carried here if need be). The resource represents the final product as it is given to the patient - possibly as mixed from the components.
Jose Costa Teixeira (Aug 14 2020 at 10:22):
From my perspective, I'm trying to give a first feedback, I don't think these resources are clear for implementation, but if we don't expose the resources, the feedback will be of low quality.
Rik Smithies (Aug 14 2020 at 10:24):
I hope I was able to answer all your questions
Jose Costa Teixeira (Aug 14 2020 at 10:25):
I was looking also at RegulatedAuthorization.indication - so we have 3 places and 3 different ways to express what a product is for - and none of them mention ConditionDefinition
Jose Costa Teixeira (Aug 14 2020 at 10:25):
Yes, the questions so far are answered - but we have work ahead
Jose Costa Teixeira (Aug 14 2020 at 10:26):
btw, I think i saw paediatrics mentioned somewhere - UK/US thing?
Rik Smithies (Aug 14 2020 at 10:27):
ConditionDefinition did not exist when that was defined
Jose Costa Teixeira (Aug 14 2020 at 10:28):
true, but it does now
Jose Costa Teixeira (Aug 14 2020 at 10:28):
will you please check MPDefinition.indication that still refers to MedicinalProductDefinitionIndication?
Rik Smithies (Aug 14 2020 at 10:29):
please "clarify 3 different ways to express what a product is for". There are several places we use ClinicalUseIssue, because that is what is needed. It is not a alternative or repeated way to say something else.
Rik Smithies (Aug 14 2020 at 10:31):
ConditionDefinition is a level 0 resource. If we need to support that, happy to consider a change request to do so
Rik Smithies (Aug 14 2020 at 10:32):
ah thanks for spotting an old bit of text there with MedicinalProductDefinitionIndication. That is out of date.
Jose Costa Teixeira (Aug 14 2020 at 10:36):
as free text, as a clinicaluseissue, and as a codeableconcept
Jose Costa Teixeira (Aug 14 2020 at 10:38):
(I hope we have a more nimble approach at this phase than making lots of change requests)
Rik Smithies (Aug 14 2020 at 10:38):
yes, ok I see what you mean, there are 3 levels supported. That is deliberate
Jose Costa Teixeira (Aug 14 2020 at 10:39):
could it be more consistent?
Rik Smithies (Aug 14 2020 at 10:40):
the idea is to cover the existing use cases, and the existing use cases are not themselves consistent. Somewhat like CodeableReference, but more fine grained because we know which use cases tend to apply where
Jose Costa Teixeira (Aug 14 2020 at 10:41):
I cannot figure out which parts have been cleared and checked and which ones are still expected to be changed, so I am treating everything as a "candidate" and provide feedback as such.
Jose Costa Teixeira (Aug 14 2020 at 10:41):
are those use cases documented? That might help me in the analysis and eventual feedback.
Jose Costa Teixeira (Aug 14 2020 at 10:42):
(note that I am just worried about 20% of the resources, overall I think the design is in a good direction, and I am trying to focus on what I would think is needed for an MVP / first good candidate)
Rik Smithies (Aug 14 2020 at 10:42):
these are level 1 resources, so all parts are subject to feedback. I don't have documented traceable requirements for all attributes in these resources, but I am happy to describe any rationale you may want information on
Jose Costa Teixeira (Aug 14 2020 at 10:50):
I think we do not have requirements for any resources, and I don't want to push that now..
Let's find some way to clarify the intended scope - but if you say "that is not in the use cases" i'd like to be able to say "then this use case is missing or incomplete".
Rik Smithies (Aug 14 2020 at 10:51):
sure
Jose Costa Teixeira (Aug 14 2020 at 10:53):
and chats are good but less efficient. Especially if one is asking about the forest or suggesting a new species of tree and you respond "which tree" (because that is really the only actionable thing we have - change requests on individual resources)
Jose Costa Teixeira (Aug 14 2020 at 10:53):
I'll do some more reading and will ping for more feedback. hopefully in a few iterations things will be clearer
Lloyd McKenzie (Aug 23 2020 at 19:02):
Coming late to the thread - my understanding was that the MedicationDefinition resources did not convey instance data - i.e. they are not specific to a single lot or serial number. Is that incorrect?
Rik Smithies (Aug 25 2020 at 19:22):
@Lloyd McKenzie yes.
I can't yet see a use case for a instance that wouldn't be easier to convey using the Medication resource (with a reference to a MedicinalProductDefinition in the background possibly, for extra detail).
However there are use cases for a PackagedProductDefinition to be an actual instance - and it already has batch numbers.
Jose Costa Teixeira (Aug 25 2020 at 19:31):
So it's not really just a definition anymore...?
Lloyd McKenzie (Aug 25 2020 at 20:11):
I don't understand PackagedProductDefinition being an instance. If it's a definition, it shouldn't ever be an instance. (And I don't think that was part of the approved scope for the resource?)
Rik Smithies (Aug 25 2020 at 20:46):
I agree, and the name isn't good for that. It was not the name that we originally wanted - and it has always had batch numbers. Nevertheless there is a use case for actual batches of things, and for all the details of the packaging. So a solution is needed. If not this resource, then something else. Any suggestions?
Jose Costa Teixeira (Aug 25 2020 at 20:48):
What is that use case for instance/batch info?
Rik Smithies (Aug 25 2020 at 20:49):
The need to represent manufactured batches of drugs, and to be able to state the packaging.
Jose Costa Teixeira (Aug 25 2020 at 20:49):
For what use case?
Rik Smithies (Aug 25 2020 at 20:50):
that is the use case :-) Manufacturing of drug batches.
Jose Costa Teixeira (Aug 25 2020 at 20:51):
Manufacturing of drug batches - how is that a use case for interoperability?
Jean Duteau (Aug 25 2020 at 20:55):
Jose Costa Teixeira said:
Manufacturing of drug batches - how is that a use case for interoperability?
It is part of supply chain management and master data management. The Packaged Product resource and its relationships allows us to clearly identify batches of product in the full detail needed for manufacturing and supply chain management. In these use cases, the limited Medication resource isn't enough.
Jose Costa Teixeira (Aug 25 2020 at 20:55):
I can imagine that need in inventory (and we're working on that); or for serialisation (and we'd need a serial number for that)
Jose Costa Teixeira (Aug 25 2020 at 20:56):
So, not definitional
Jean Duteau (Aug 25 2020 at 20:56):
depends on your definition of definitional :). It is defining the product, its packaging, and the associated identifiers for use in a supply chain.
Jose Costa Teixeira (Aug 25 2020 at 20:56):
And I still don't see the use case (tbh I didn't see it in idmp either)
Rik Smithies (Aug 25 2020 at 20:57):
@Jose Costa Teixeira this is not IDMP.
Jean Duteau (Aug 25 2020 at 20:57):
"I still don't see the use case" I don't know why you keep saying that. I've defined the use case and you don't understand it? Or you understand it but don't see a need for it?
Jose Costa Teixeira (Aug 25 2020 at 20:58):
The use case I imagine is : manufacturer declares to the regulator the following batches have been put on the market today.
Jean Duteau (Aug 25 2020 at 20:59):
yes, that is also a good use case. but that's not the use case I was detailing. In the use case I was detailing, the manufacturer is detailing what has gone into the batch of product they produced and uses that when sending to other parties in the supply chain.
Jose Costa Teixeira (Aug 25 2020 at 21:00):
That is a supply chain issue, and is not a regulatory submission issue.
Jose Costa Teixeira (Aug 25 2020 at 21:00):
So if those are the use cases (which seem close) we should handle that in the supply chain
Rik Smithies (Aug 25 2020 at 21:02):
This is information that drug companies submit to regulators. So it is regulatory, though I don't see why it matters.
Jose Costa Teixeira (Aug 25 2020 at 21:03):
Supply chain for regulators should follow the practices of supply chain
Jose Costa Teixeira (Aug 25 2020 at 21:04):
So I think there is a case but I don't understand why these resources are making a partial solution for a problem that is broader
Rik Smithies (Aug 25 2020 at 21:07):
It's about regulation of the manufacture of drugs and the information content fits squarely into the package resource - because it a lot to do with packaging of medications. We don't want to describe a packaged thing differently at different times, or when it later becomes "supply chain".
Jose Costa Teixeira (Aug 25 2020 at 21:07):
@Rik Smithies I know this is not idmp, but I saw the same antipattern here as idmp.
Rik Smithies (Aug 25 2020 at 21:11):
So anyway, the issue is how to represent all the packaging of medicinal item, and also have instance data of identifiers and dates.
Jose Costa Teixeira (Aug 25 2020 at 21:16):
Definitional resources are for master data, and inventory can also be seen as master data but the lifecycles are different.
Jose Costa Teixeira (Aug 25 2020 at 21:18):
So anyway, the issue is how to represent all the packaging of medicinal item, and also have instance data of identifiers and dates.
One resource for the definitional side, and another for the instance. These resources will be used differently and updated differently
Jose Costa Teixeira (Aug 25 2020 at 21:23):
@Rik Smithies the proposal says "The core basis for the resource is the information in ISO 11615"... Which explains the inherited issue/mix.
Jose Costa Teixeira (Aug 25 2020 at 21:28):
I don't grasp the detailed scope and intent of these resources.
Jose Costa Teixeira (Aug 25 2020 at 21:30):
The requirement and use cases are not clear so I have to guess a bit. But that is manageable
Jose Costa Teixeira (Aug 25 2020 at 21:31):
My suggestion would be to reconsider the batch info in these resources
Jose Costa Teixeira (Aug 25 2020 at 21:33):
I.e. remove them
Rik Smithies (Aug 25 2020 at 21:45):
we may need to use Medication for the instance and PackagedProductDefinition for the packaging info
Vassil Peytchev (Aug 25 2020 at 21:51):
I see several XProductDefinition resources, but no XProduct resources... Are all instances going to be Medication then?
Jose Costa Teixeira (Aug 25 2020 at 22:02):
@Vassil Peytchev good question. Proposal seems to indicate that.
Jose Costa Teixeira (Aug 25 2020 at 22:03):
These resources are apparently medication-centric. One of my quests is to compare this with the Healthcare Product discussions which should be valid for medication or devices or nutrition
Rik Smithies (Aug 25 2020 at 22:09):
Instances will be Medication yes. Probably in every case - but that is this discussion.
Day to day prescribing is Medication and not the Medication Definition resources, that has always been the plan. (Medication is used for both instance and also sometimes definition though btw).
There are some regulatory manufacturing use cases that we are discussing that are somewhat between instance and definition. These are "test batches", and submitted to regulators as part of the drug approval process, so are partly definitional - like a template - but they have dates and identifiers, so have an instance aspect.
Jose Costa Teixeira (Aug 25 2020 at 22:29):
Reporting of test batches seems a different use case.
Rik Smithies (Aug 25 2020 at 23:09):
Yes, it is a different use case - but it needs similar data elements.
Lloyd McKenzie (Aug 25 2020 at 23:18):
If the use-case is notifying the regulator that a particular batch has been produced - to allow subsequent supply chain tracing - I don't understand why you wouldn't have a Medication instance that points to the Definition instead of using a Definition instance for two different purposes - one of which clearly isn't a definition.
Rik Smithies (Aug 25 2020 at 23:30):
yes I was suggesting exactly that just earlier in the thread
Lloyd McKenzie (Aug 26 2020 at 00:20):
Ok, so the definition resources wouldn't need to expose 'lot' then, correct?
Rik Smithies (Aug 26 2020 at 00:24):
that's right
Jose Costa Teixeira (Aug 28 2020 at 09:41):
There are not many value sets and bindings on these resources. Is that intentional? Why not put examples like EDQM?
Jose Costa Teixeira (Aug 28 2020 at 09:42):
also, "paediatricUseIndicator" - is a codeableConcept - why?
Jose Costa Teixeira (Aug 28 2020 at 09:42):
(just found these ones).
Jose Costa Teixeira (Aug 28 2020 at 09:43):
I'm expecting these resources to be rather generic, and then EMA / FDA would have to constrain them, but I don't see those constraints.
Rik Smithies (Aug 28 2020 at 11:03):
-is that intentional
This work has just not been done yet.
-paediatricUseIndicator
Is coded so you can have a variety of values, not just yes/no or true/false. e.g. "for use in infants", "not for under 12s" etc.
-I'm expecting these resources to be rather generic
Agree
-and then EMA / FDA would have to constrain them
Yes
-but I don't see those constraints
If they are constrained by those organizations, then those constraints won't be visible in the resources themselves.
Jose Costa Teixeira (Aug 28 2020 at 11:42):
Pediatric - why not code? Do we want free text in submissions?
Jose Costa Teixeira (Aug 28 2020 at 11:44):
I was looking at the ema ig and they pretty much point to the resources as if it's ready out of the box.. as long as they are aware that there is still a lot to do (some on the core, a lot on their IG), we're fine
Rik Smithies (Aug 28 2020 at 12:12):
-why not code
Afaik MnM guidelines recommend using CodeableConcept for general use in resources
Jose Costa Teixeira (Aug 28 2020 at 13:45):
This is not a field where I would expect people to add free text values. I expect this to be reference data available somewhere
Jose Costa Teixeira (Aug 28 2020 at 13:47):
(right?)
Rik Smithies (Aug 28 2020 at 13:49):
yes I agree
Rik Smithies (Aug 28 2020 at 13:53):
usually it would be a single code, but this can also be used for a general description of the paediatric use, and also MnM guidance says to prefer CodeableConcept datatype
Jose Costa Teixeira (Aug 28 2020 at 14:03):
for a general description - then we cn change to coding and use use coding.display
I don't know how the MnM guidance would apply here - if we want to exclude free text, why use CodeableConcept?
Lloyd McKenzie (Aug 28 2020 at 14:13):
If there's a chance of code translations being needed, CodeableConcept is appropriate.
Rik Smithies (Aug 28 2020 at 14:14):
Coding.display is not for a general description. It's for the fixed display text of the code.
Re MnM Im not sure what to say - MnM guidance says to use CodeableConcept in general unless there is a very strong reason why not. We had several Codings in these resources at one stage, but were specifically asked to change them to CodeableConcepts.
Jose Costa Teixeira (Sep 12 2020 at 08:45):
This is regulatory stuff, I'd expect the reference data to be defined for one domain. I don't see where we'd have several translations in one produce code.
Jose Costa Teixeira (Sep 12 2020 at 08:47):
I'm sure the MnM guidance comes with a context - code is not deprecated afaik. Perhaps this shouldn't be code, I just don't see a reason.
Jose Costa Teixeira (Sep 12 2020 at 08:52):
Related to feedback: I can't create a Jira ticket on MedicinalProductDefinition. The resource is not shown in the dropdown box
Jose Costa Teixeira (Sep 12 2020 at 08:54):
For this resource, scope should be clarified - explicit, not by exclusion. Currently it gives the idea that is resource covers everything except clinical use (which is not the case judging from recent discussions - this is not intended to cover unknown/eventual scopes).
Rik Smithies (Sep 12 2020 at 08:58):
Jira doesn't have the R5 names, only R4, so you have to use those
Rik Smithies (Sep 12 2020 at 09:02):
The resources are not just regulatory, they are for any situation where you need the full information, such as a drug dictionary, or pharmacopeia. And even regulatory is not "one domain" with single code systems defined for codes. "Regulatory" is a big area.
Jose Costa Teixeira (Sep 12 2020 at 09:18):
Where are the mappings so that I can figure out which resource to use in Jira? @Lloyd McKenzie (or perhaps add the page)
Jose Costa Teixeira (Sep 12 2020 at 09:19):
And I don't think you can say "for any situation" after the debate where you don't want to consider "eventual" scope. (you = BRR)
Jose Costa Teixeira (Sep 12 2020 at 09:20):
We either make sure the resource is valid for any situation (including new ones), or we define our scope better.
Jose Costa Teixeira (Sep 12 2020 at 09:25):
You can e.g. exclude homeopatic, or supply chain (known unknowns), but that still makes the resource scope inconsistent with the previous discussions.
Rik Smithies (Sep 12 2020 at 09:25):
We can consider new situations when we have requirements for new situations. It's not good to add speculative requirements, nor to say we are are done and won't be accepting any more requirements.
Jose Costa Teixeira (Sep 12 2020 at 09:28):
This is difficult.... So if say "this resource should support also this case but requires a redesign" - I seem to get "no, that is not in scope". But when I need to understand the scope, i get "scope can be anything, depends on the use cases".
Jose Costa Teixeira (Sep 12 2020 at 09:30):
These are not requirements. This is a scope discussion. I am not talking about the quality of the resources , but the scope of one resource. If that is not clear...
Jose Costa Teixeira (Sep 12 2020 at 09:31):
We really want to use these resources, and put them to test, but I sense a resistance like when feedback is not really welcome.
Rik Smithies (Sep 12 2020 at 09:40):
I welcome your feedback Jose, please just give us specific changes that you would like to be made. I also suggest to start using the resources, and to put them to the test.
Jose Costa Teixeira (Sep 12 2020 at 09:58):
I just gave feedback
Jose Costa Teixeira (Sep 12 2020 at 09:59):
Make the scope explicit about what is covered, not "anything except..."
Rik Smithies (Sep 12 2020 at 10:02):
We do want to be completely explicit about what is in scope, but have not yet decided what will be in scope eventually. For example we don't know what aspects of devices should be in scope. Analysis work needs to be done before we make that decision. I think we are working towards the clarity that you want, but we are not there yet. And we are not saying we are done.
Jose Costa Teixeira (Sep 12 2020 at 10:19):
Then please be explicit. Indicate what it covers. Do not indicate it can cover anything else except the known exclusions. If and when you include devices, you can add that to the scope. But do not leave this deliberately open - that seems in contrast with email discussions
Jose Costa Teixeira (Sep 12 2020 at 10:21):
My feedback is simple, I think: make the scope explicit. The initial scope was regulatory for medicines. Expand the scope to the use cases you included since. This is for consistency with previous email discussions - which I disagree but I respect
Rik Smithies (Sep 12 2020 at 10:31):
thanks for the feedback Jose
Lloyd McKenzie (Sep 12 2020 at 14:40):
@Rik Smithies - you can and should make a pull request against Jira-Spec-Artifacts to change the names in Jira (adding the old ones in brackets, like we did for CapabilityStatement).
Jose Costa Teixeira (Oct 19 2020 at 11:25):
I don't know if this is done yet - Is it there?
I wanted to follow up on one of my previous issues was too vague (about the use of codes vs codeableconcepts) and I can submit more precise change proposals if adequate
Rik Smithies (Oct 19 2020 at 12:30):
I have not had a chance to do this yet no, sorry. You can still submit comments.
Rik Smithies (Oct 23 2020 at 18:33):
@Lloyd McKenzie I'm getting a 403 error on push. Do I need permission?
Lloyd McKenzie (Oct 23 2020 at 18:39):
What are you trying to push to?
Rik Smithies (Oct 23 2020 at 18:51):
I tried to push to origin, but it then says: fatal: unable to access 'https://github.com/HL7/JIRA-Spec-Artifacts/': The requested URL returned error: 403.
Rik Smithies (Oct 23 2020 at 18:54):
by the way should I add new resource artifacts and leave the old? If I delete the old it complains, understandably. But what is the thing with the brackets? Does that refer to the old name, but the old name is still left there? Is it just a comment for humans?
Lloyd McKenzie (Oct 23 2020 at 23:07):
You have to make a local repository and then submit a pull request. You can't push directly
Rik Smithies (Oct 23 2020 at 23:08):
I do have a local copy and a build. Is that not a local repository?
Rik Smithies (Oct 23 2020 at 23:08):
I've obviously not done it right. I will try to clone the repo again.
Lloyd McKenzie (Oct 23 2020 at 23:15):
You should be able to commit to your personal repository. Create a pull request from that.
Last updated: Apr 12 2022 at 19:14 UTC
