Stream: BRR - Pharmacy model
Topic: RouteOfAdministration.TargetSpecies.WithdrawalPeriod
Jose Costa Teixeira (Oct 24 2020 at 17:45):
Why is TargetSpecies under RouteOdAdministration?
And WithdrawalPeriod - why are those not independent (so that you can have facets for searching)?
Rik Smithies (Oct 26 2020 at 12:48):
This was modelled by the veterinary team at EMA to match the way this works across Europe.
So it's just one data point of how this data is captured. When we have more domain views it can of course be updated to cover those as well.
Jose Costa Teixeira (Oct 26 2020 at 17:48):
That is not a compelling argument. I would expect that WithdrawalPeriod applies to the drug, not to a specific RouteOfAdministration.
Jose Costa Teixeira (Oct 26 2020 at 17:49):
Can we consider TargetSpecies as part of something else (ClinicalUseIssue perhaps) ?
Rik Smithies (Oct 26 2020 at 18:10):
We need route to be related to species. And withdrawal period is species specific too.
If you want to add species to ClinicalUseIssue feel free to propose that.
Jose Costa Teixeira (Oct 26 2020 at 18:11):
Rik Smithies said:
We need route to be related to species. And withdrawal period is species specific too.
You can relate route to species by means of the product indications, it is not an intrinsic characteristic of the product itself.
Similar for withdrawal period.
Rik Smithies (Oct 26 2020 at 18:12):
I am just basing this on the way it is captured in current implementations.
Jose Costa Teixeira (Oct 26 2020 at 18:13):
Do I understand correctly that EMA Veterinary team proposed such a model (I think this is not how IDMP has it), and that is what we stick to? Nodoby at BRR advanced that maybe this is not the way to handle this?
Rik Smithies (Oct 26 2020 at 18:15):
Yes to the first question, this is the way it is done in the EU. Indeed it is not in IDMP. If you have any information about how other projects handle this information that would be useful data.
Jose Costa Teixeira (Oct 26 2020 at 18:17):
This is the way it is done in the EU? In all the 27 countries?
Jose Costa Teixeira (Oct 26 2020 at 18:17):
Is there any product dictionary that actually defines this in such a way?
Rik Smithies (Oct 26 2020 at 18:18):
It is the way EMA do it and they have jurisdiction over 27 countries, that is correct. I am not a vet expert. I know of no product dictionary for this area.
Jose Costa Teixeira (Oct 26 2020 at 18:19):
That is the wrong message to send. EMA is NOT dictating what current systems do. EMA has proposed a model. If you do not know the product dictionaries, it's good to get feedback (like I'm giving), instead of saying "the EMA told us, so it must be what everyone else is doing".
Jean Duteau (Oct 26 2020 at 18:20):
FDA appears to report this information the same way - based on route, species, there is a specified withdrawal time. We might need to have dose and/or duration in that element to support the FDA withdrawal times
Rik Smithies (Oct 26 2020 at 18:20):
It's a draft model Jose. If you have other information about how current practice works, please bring it forwards.
Rik Smithies (Oct 26 2020 at 18:21):
I certainly didn't say it is what everyone else is doing. I said it was a first data point.
Jose Costa Teixeira (Oct 26 2020 at 18:22):
This is FMM1, so I was asking "how draft is this"
And I was just asking questions - first responses seemed to be indicating that this is what it is, but I 'm happy that there is some space for discussing.
Jean Duteau (Oct 26 2020 at 18:22):
i just checked Health Canada and they also specify withdrawal times based on route, dosage, and form (and obviously species)
Jose Costa Teixeira (Oct 26 2020 at 18:24):
(I don't want to research any models if the feedback is not appreciated.
I'm glad we can have feedback, and I will see how this can be done, and bring an alternative for discussion. For a second you had me worried there)
Rik Smithies (Oct 26 2020 at 18:25):
Jose, good feedback is always welcome, and we always discuss with you.
Jose Costa Teixeira (Oct 26 2020 at 18:27):
I hope so, I want to see if these resources can get in a decent shape to go out there, but we need to work on them.
Jean Duteau (Oct 26 2020 at 18:28):
Jose - you do know that these resources are being used in current implementation projects as they are?
Jose Costa Teixeira (Oct 26 2020 at 18:30):
I was told that, yes. Are we supposed to say "this is ok then?"
Jean Duteau (Oct 26 2020 at 18:31):
do you have implementation experience that contradicts the findings of those projects?
Jean Duteau (Oct 26 2020 at 18:32):
Rik can only do what he can do - model the data elements he has been told to model in the best way he can and rely on implementer feedback to correct it.
Jose Costa Teixeira (Oct 26 2020 at 18:32):
We have too many resources that I can't see how we can use in clinical workflows. We could make things much clearer, simpler, and much more supportive of IDMP.
Jose Costa Teixeira (Oct 26 2020 at 18:32):
Jean Duteau said:
do you have implementation experience that contradicts the findings of those projects?
??
Jean Duteau (Oct 26 2020 at 18:34):
Jose Costa Teixeira said:
Jean Duteau said:
do you have implementation experience that contradicts the findings of those projects?
??
We have three implementation projects that are using the resources and have provided specific issues back to BR&R. The resources have changed quite a bit based on that feedback. Since you are asking questions, I'm just asking if your implementation project has found bigger problems with the resources that those other projects didn't see.
Jose Costa Teixeira (Oct 26 2020 at 18:35):
Jean Duteau said:
Rik can only do what he can do - model the data elements he has been told to model in the best way he can and rely on implementer feedback to correct it.
Don't misunderstand me. I appreciate the enormous effort that @Rik Smithies has done. This is not about that, it is about getting more collaboration inside HL7. The amount of work to make this more robust (maybe) is less than these repeating discussions.
Jose Costa Teixeira (Oct 26 2020 at 18:53):
Jean Duteau said:
Jose Costa Teixeira said:
Jean Duteau said:
do you have implementation experience that contradicts the findings of those projects?
??
We have three implementation projects that are using the resources and have provided specific issues back to BR&R. The resources have changed quite a bit based on that feedback. Since you are asking questions, I'm just asking if your implementation project has found bigger problems with the resources that those other projects didn't see.
???
So I need to have a running implementation project to provide feedback? Being involved in projects that will need to use this across borders, trying to adopt this into IHE, knowing a bit of IDMP is not sufficient to ask questions?
Jose Costa Teixeira (Oct 26 2020 at 18:53):
that makes sense. And explains the state of these resources.
Jean Duteau (Oct 26 2020 at 18:59):
Jose Costa Teixeira said:
Jean Duteau said:
We have three implementation projects that are using the resources and have provided specific issues back to BR&R. The resources have changed quite a bit based on that feedback. Since you are asking questions, I'm just asking if your implementation project has found bigger problems with the resources that those other projects didn't see.
???
So I need to have a running implementation project to provide feedback? Being involved in projects that will need to use this across borders, trying to adopt this into IHE, knowing a bit of IDMP is not sufficient to ask questions?
Sorry, I wasn't saying that you had to have an implementation project to provide feedback. I just assumed that these issues you were raising were due to an implementation you were working on. My three projects are admittedly not using the full scope of the resources, but we haven't any real show-stoppers. And I was worried that I was missing something. :)
Rik Smithies (Oct 26 2020 at 19:07):
But it is true that FHIR is for implementers. We can theorize, but it is what implementations need and find out that counts most.
Jose Costa Teixeira (Oct 26 2020 at 20:07):
Rik Smithies said:
But it is true that FHIR is for implementers. We can theorize, but it is what implementations need and find out that counts most.
that makes sense. And explains the state of these resources.
Rik Smithies (Oct 26 2020 at 20:08):
you mean - fit for implementers?
Jose Costa Teixeira (Oct 26 2020 at 20:34):
I don't know what else to say.
Regulators will take this and will not appreciate giving one step back. So whatever we do now, it's going to be hard to iterate in fundamental aspects.
We will hear "sorry, the regulators are already doing this, we should not force them to go back".
Jose Costa Teixeira (Oct 26 2020 at 20:36):
No, I do not think these resources are fit for implementers. I do not know the timing of R4B, but I think the time we have would be best spent with dialog instead of trying to convince me that this is what the world needs right now.
Jose Costa Teixeira (Oct 26 2020 at 20:40):
I do not think these resources merit a dedicated release.
Jose Costa Teixeira (Oct 26 2020 at 20:41):
My change proposals:
- Merge MedicinalProductDefinition, AdministrableProductDefinition, PackageProductDefinition into 1 (much better for IDMP adoption). This removes some overlap, supports non-IDMP implementations better, and still allow us to make profiles.
- Review the use of CodeableConcept instead of code for some attributes.
- Separate Package from ProductDefinition. We need the notion of Package, and that one you have is a good one, it doesn't deserve to be buried under a "product"
- Remove Ingredient as a dedicated resource
Rik Smithies (Oct 26 2020 at 20:43):
But it is up to the implementers to say if this is fit for implementers.
Rik Smithies (Oct 26 2020 at 20:44):
And they need a release to try. Currently none of this is in any release.
Rik Smithies (Oct 26 2020 at 20:44):
IDMP implementers want the resource split as it is, that is the feedback I am getting.
Jose Costa Teixeira (Oct 26 2020 at 20:44):
You asked me if I meant they were fit for purpose. I answered
Jose Costa Teixeira (Oct 26 2020 at 20:48):
IDMP is not only for regulators. And I'm getting different feedback.
We could simply find a meeting point and I think you would accommodate some of the changes if you would consider them; implemeters would not be less satisfied if we did.
Rik Smithies (Oct 26 2020 at 20:49):
Ok great, bring your implementation feedback forward and we can work with it.
Jose Costa Teixeira (Oct 26 2020 at 20:50):
Again, I get to give feedback only when I have an implementation?
Rik Smithies (Oct 26 2020 at 20:50):
no, but again, implementation feedback is king. FHIR is for implementers.
Rik Smithies (Oct 26 2020 at 20:52):
If we have several views, then the one that real systems and real developers give is the more weighty.
Jose Costa Teixeira (Oct 26 2020 at 20:52):
Sorry, I think this is again the same discussion with little substance.
I brought the feedback.
Jean Duteau (Oct 26 2020 at 20:55):
Jose Costa Teixeira said:
My change proposals:
- Merge MedicinalProductDefinition, AdministrableProductDefinition, PackageProductDefinition into 1 (much better for IDMP adoption). This removes some overlap, supports non-IDMP implementations better, and still allow us to make profiles.
- Review the use of CodeableConcept instead of code for some attributes.
- Separate Package from ProductDefinition. We need the notion of Package, and that one you have is a good one, it doesn't deserve to be buried under a "product"
- Remove Ingredient as a dedicated resource
@Jose Costa Teixeira I see two of those in JIRA. Have you raised the other ones yet? And you probably want to raise this issue on JIRA as well?
Jose Costa Teixeira (Oct 26 2020 at 20:56):
I do not want to discuss how the proposals don't have merit because this is not an implementation feedback.
I know a bit about IDMP and catalogs and supply chain, and that is exactly why i give this feedback.
Jose Costa Teixeira (Oct 26 2020 at 20:58):
@Jean Duteau Of course I will raise the other issues, but the fundamental one (#1) is already there. Once we discuss that one, we will actually start a dialog, then we will see if the other s make sense - and maybe during a constructive dialog I will even reconsider my perspective.
Jean Duteau (Oct 26 2020 at 20:59):
Jose Costa Teixeira said:
Jean Duteau Of course I will raise the other issues, but the fundamental one (#1) is already there. Once we discuss that one, we will actually start a dialog, then we will see if the other s make sense - and maybe during a constructive dialog I will even reconsider my perspective.
Yes, I see #1 and #2, but I didn't see #3 or #4 and I wanted to make sure they were in JIRA. Thanks.
Rik Smithies (Oct 26 2020 at 20:59):
There is much discussion on your #1 Jira Jose
Lloyd McKenzie (Oct 26 2020 at 21:15):
Has the work group considered an "A/B" approach like we've done with CarePlan, CapabilityStatement and a few other resources - publish two competing approaches and try them out at connectathon to see what works better/is more appealing to the community? (Not saying that's the only way to settle this discussion, but wanted to raise it as an option.)
Jose Costa Teixeira (Oct 26 2020 at 21:16):
There is an opening for discussion, not that much discussion, perhaps because I think a dialog (in a call) would be more efficient.
Rik Smithies (Oct 26 2020 at 21:18):
We haven't done such an A/B approach yet. Interesting idea though.
Jose Costa Teixeira (Oct 26 2020 at 21:24):
I think an A/B would make sense. A coexistence of resources would make it clear that I don't want to disconsider the work done so far by Rik, it's just a slightly different perspective. If we can live with overlap and touch base at some regular points, I think that makes sense.
Jean Duteau (Oct 26 2020 at 21:33):
Lloyd McKenzie said:
Has the work group considered an "A/B" approach like we've done with CarePlan, CapabilityStatement and a few other resources - publish two competing approaches and try them out at connectathon to see what works better/is more appealing to the community? (Not saying that's the only way to settle this discussion, but wanted to raise it as an option.)
@Lloyd McKenzie How early in the process of creating CarePlan and those other resources did the A/B approach happen?
Obviously, we have some existing implementations that have worked with the existing resource design. I'm wondering how we get someone to test an alternative approach?
Rik Smithies (Oct 26 2020 at 21:33):
It needs to be brought to a decision fairly soon and not be a long running alterative approach.
Rik Smithies (Oct 26 2020 at 21:34):
That will only confuse people.
Jean Duteau (Oct 26 2020 at 21:34):
can @Jose Costa Teixeira produce his alternative suggestion in the build and then we can sign up implementers to try out the two alternatives?
Rik Smithies (Oct 26 2020 at 21:35):
I would think that a workgroup view on the relevant Jira would be a good step. If there is consensus, then we don't need to explore every approach at length.
Jean Duteau (Oct 26 2020 at 21:37):
Rik Smithies said:
I would think that a workgroup view on the relevant Jira would be a good step. If there is consensus, then we don't need to explore every approach at length.
Sure. I just didn't understand exactly what Jose's suggestion was from the details in the JIRA ticket, so by getting him to create it and put it in the build, we'd have something more concrete to review at the BR&R call and also to get implementers to try out.
Jose Costa Teixeira (Oct 26 2020 at 21:39):
I am up to discussing the Jira and if there is no consensus we can release concurrent resources and accept the overlap. That may be a good timing time to start supporting the UNICOM needs when they arrive.
Rik Smithies (Oct 26 2020 at 21:42):
The thing to do would be to ask for agenda time.
Jean Duteau (Oct 26 2020 at 21:48):
@Jose Costa Teixeira I personally don't know what you are suggesting in your JIRA ticket (J#28581). Peter Bomberg also said the same thing in his comments. I think that you would be best served by creating the one resource and the three profiles. I don't think you need to do that in the build but that would certainly help. Creating a UML representation of what you are proposing as well as some examples using your structure would certainly help move the conversation along.
Without that, I can't really agree to your proposal because I just don't understand the ramifications of it.
Jean Duteau (Oct 26 2020 at 21:50):
Once you have this representation, we can request the implementers to take a look and comment on it as well as schedule it for the next connectathon to get some implementer feedback on the two proposed solutions. Thanks.
Jean Duteau (Oct 26 2020 at 21:52):
NOTE: By implementers, i know of the PQ/CMC team, Peter Bomberg from Health Canada, the EMA team that is implementing IDMP, and myself in the FDA SPL project. @Rik Smithies are there other implementers we can reach out to?
Rik Smithies (Oct 26 2020 at 21:54):
the SAFEST project in Norway
Jose Costa Teixeira (Oct 26 2020 at 22:08):
I'll ask for a few implementers soon
Lloyd McKenzie (Oct 26 2020 at 22:08):
For CarePlan, I think they did it in the lead-up to STU2. For CapabilityStatement, it was in the lead-up to STU3.
Lloyd McKenzie (Oct 26 2020 at 22:10):
I agree with Jean that a concrete model and a few examples would probably accelerate the conversation - though obviously that's not a tiny amount of work.
Rik Smithies (Oct 26 2020 at 22:11):
If its a reasonable proposal - intended to simplify - it must be capable of being explained clearly and succinctly
Jean Duteau (Oct 26 2020 at 22:12):
i agree. Jose can certainly add his model and examples to the issue.
Jean Duteau (Oct 26 2020 at 22:19):
Jean Duteau said:
Once you have this representation, we can request the implementers to take a look and comment on it as well as schedule it for the next connectathon to get some implementer feedback on the two proposed solutions. Thanks.
I shouldn't have presumed on the part of the BR&R WG. There is obviously a step in between having the representation and requesting implementer feedback and that is BR&R accepting the proposal on its merits.
Jose Costa Teixeira (Oct 26 2020 at 22:26):
Sorry but I want to be sure I'm not lost. Is this a proposal for pushing out and see what implementers and others feel about it, or is this adding a couple of resources and examples so that BRR can see if it was worth the effort and if this is allowed to move?
Jose Costa Teixeira (Oct 26 2020 at 22:27):
in other words, do we want to have implementations with A/B testing, or is it just for internal review?
Jose Costa Teixeira (Oct 26 2020 at 22:28):
If there is an expectation that this will be pushed out, of course I can work on it.
Jose Costa Teixeira (Oct 26 2020 at 22:31):
in other words, if I produce a plan B, and suppose there is no consensus (because BRR says things actually work and don't consider the broader scope and simplicity to be persuasive enough to have competing resources), what happens?
we still have a limited duration for A/B? Or plan B is going to be rejected?
Jose Costa Teixeira (Oct 26 2020 at 22:34):
I think we are getting somewhere , but "trying both options at a connectathon" is the starting assumption, right?
Jose Costa Teixeira (Oct 26 2020 at 22:36):
Jean Duteau said:
Jean Duteau said:
Once you have this representation, we can request the implementers to take a look and comment on it as well as schedule it for the next connectathon to get some implementer feedback on the two proposed solutions. Thanks.
I shouldn't have presumed on the part of the BR&R WG. There is obviously a step in between having the representation and requesting implementer feedback and that is BR&R accepting the proposal on its merits.
No, the step in between is that BRR accepts having a parallel option to submit to implementers, even if that may not be the way BRR prefers it now.
Jean Duteau (Oct 26 2020 at 22:37):
Currently, there are comments on your JIRA issue that shows that some don't understand what you are asking for. To help those people (of who I am one) and the BR&R WG understand your ask and allow it to go forward, I am requesting that you create the one resource you are proposing, the profiles that would allow IDMP work to use that resource, and some examples to show us the simplicity you are requesting. As I said, this doesn't necessarily need to be actual resources in the build right now, but something that will allow people to understand what you are requesting. Without that, I suspect your proposal will simply be found not persuasive. Once we understand what you are requesting, and assuming that the BR&R WG sees the merit of your suggestion (I'm presuming they will, but I'm just one member), then you will need to create actual resources in the build (assuming you didn't already do that), so that implementers can test the two different models with the Implementation Guides and implementations and provide their feedback on a way forward for BR&R to adopt.
Jose Costa Teixeira (Oct 26 2020 at 22:42):
This is not what we were discussing, I think.
Rik Smithies (Oct 26 2020 at 22:43):
I would against progressing to real A/B testing unless there is some consensus on the two models being realistic options. That needs a committee decision. If it helps to have more examples to understand the proposal then that is good too.
Jose Costa Teixeira (Oct 26 2020 at 22:43):
That is clear. We are back to the starting point.
Jose Costa Teixeira (Oct 26 2020 at 22:44):
For a second, I did have hope that we'd work on this together. I was even preparing to do the work and create different resources, sinceI would expect this to be something we could show to implementers.
Rik Smithies (Oct 26 2020 at 22:45):
Jose - bring your proposal to the workgroup. Nothing can happen without workgroup review.
Rik Smithies (Oct 26 2020 at 22:46):
If the workgroup cannot decide between two approaches, then we could decide to try both.
Rik Smithies (Oct 26 2020 at 22:47):
When your proposal is ready, bring it forward.
Jose Costa Teixeira (Oct 26 2020 at 22:48):
Rik Smithies said:
If the workgroup cannot decide between two approaches, then we could decide to try both.
Sorry, perhaps I am tired. Whay you say now is actually the only assurance I think is reasonable to ask - that BRR does not feel that they have to choose between two approaches (as long as they are implementable); and in case of lack of agreement, we agree that both will be published.
Rik Smithies (Oct 26 2020 at 22:50):
It is normal to just make a decision. We don't make multiple copies of most things. But in cases where a decision cannot be reached, then we could try both.
Lloyd McKenzie (Oct 26 2020 at 22:50):
I think "express the proposal as a model" is a useful starting point. That will allow the work group to better understand what's proposed and to better see the costs/benefits. It's possible that once made concrete, there will be obvious flaws/deficiencies that aren't correctable. In that case, there'd be no need to proceed to a bake-off connectathon. Alternatively, the work group might see that the new approach is clearly better and decide to switch - in which case there'd also be no need to a bake-off. If the work group looks at the alternative and decides "yes this could work, but we can't decide on whether the trade-offs are worth it", then a bake-off would guide the eventual decision. The work group can also choose to allow both to proceed to ballot and allow the community to provide feedback. However, prior to publication, the work group will have to choose one horse to ride - at least until after the publication is out
Jose Costa Teixeira (Oct 26 2020 at 22:51):
So I agree with this last bit, and that is the starting assumption. This is going to be a lot of discussions with people from different areas (which I hope BRR can facilitate) and implement resources.
Jose Costa Teixeira (Oct 26 2020 at 22:51):
@Lloyd McKenzie you lost me there with bake-off and with your last sentence
Rik Smithies (Oct 26 2020 at 22:55):
The main thing is that the workgroup decides. There is not a workgroup effort and then other things that are held up as alternatives, outside of the workgroup.
Jean Duteau (Oct 26 2020 at 22:56):
@Jose Costa Teixeira by "bake-off" Lloyd meant that the connecathon would have as its goal to determine which of the two alternative worked best for implementers. And Lloyd's last sentence was simply stating that you could even let the alternatives go to ballot but that, before publication occurred, one alternative would need to be chosen.
Jose Costa Teixeira (Oct 26 2020 at 22:59):
I think I understand. Of course the workgroup decides. I just need to assume that the workgroup is willing to let an alternative see the daylight, even if it is not the currently preferred option.
Jose Costa Teixeira (Oct 26 2020 at 23:00):
this gives the workgroup more time and more insight before making a more final cut.
Jose Costa Teixeira (Oct 26 2020 at 23:00):
(right?)
Rik Smithies (Oct 26 2020 at 23:02):
It's not about willingness. Your job, as it has been from the start, is simply to convince the workgroup that your ideas are better. If you can, job done. If you can't, I hope you accept that. In the case where the workgroup really cannot make up its mind (very unusual, but it has happened I believe), they could try both.
Jose Costa Teixeira (Oct 26 2020 at 23:21):
I'm lost again. I was already working on the proposal but I guess this means "give it your best shot, you have a short time, and if we think our idea is better, there is no A/B testing, we just stick to what we have"
Jose Costa Teixeira (Oct 26 2020 at 23:23):
if that is correct, I do not know what to do.
The first proposal is relatively clear, I think - merge the resources types, because there are duplicate attributes, and because you would want this to support non-IDMP concepts as well without having to contain other resources or having extensions.
Jose Costa Teixeira (Oct 26 2020 at 23:24):
I expressed my early interest in a call to discuss, and I was happy with entertaining the A/B scenario. I guess i misunderstood.
Rik Smithies (Oct 26 2020 at 23:25):
We can't discuss the discussion much more Jose. Just bring your ideas to the workgroup as everyone does with all change proposals.
Jose Costa Teixeira (Oct 26 2020 at 23:28):
https://jira.hl7.org/browse/FHIR-28581
Jose Costa Teixeira (Oct 26 2020 at 23:28):
I would have preferred an A/B approach (as I understood it)
Rik Smithies (Oct 26 2020 at 23:29):
All routes go via the workgroup Jose.
Jean Duteau (Oct 26 2020 at 23:32):
@Jose Costa Teixeira Here is what Lloyd and I are suggesting you do:
1) Express your proposal as a model. Your proposal as expressed in the JIRA issue is not very clear beyond a statement of reducing perceived duplication. So create some diagrams and some examples that convey the existing resource data elements in your proposed new way. If you want to express it as actual FHIR resources, that would be even better. Once you are done, update your JIRA ticket with the diagrams, examples, and/or pointer to the FHIR resources.
2) Come to a BR&R call to discuss your model proposal. Explain how it achieves your desired end goal. Based on the discussion, BR&R may decide to accept your proposal, to reject your proposal, or to allow both proposals to be expressed in the build for implementer feedback.
3) Assuming that BR&R agrees that your proposal has merit, then complete the work in the current FHIR build so that it can be dealt with at an upcoming FHIR connectathon.
4) At the connectathon, existing implementers will review, discuss, implement both proposals and provide their feedback back to the workgroup.
5) Armed with the connectathon feedback, BR&R will either decide on one or the other proposals or they may allow both to go to ballot to get even wider feedback.
6) After ballot and before publication, the chosen proposal will be kept in the build.
Hope this makes sense.
Lloyd McKenzie (Oct 27 2020 at 00:00):
I think Jose's looking for clarity about whether he has authorization to create 'proposed' alternate resources in the FHIR build. Doing that doesn't technically require a work group's authorization - but they should be clearly flagged as draft/temporary. So no work group gateway there. The work group will need to approve them to be in the ballot - and should be involved in the decision to test them at connectathon.
Jean Duteau (Oct 27 2020 at 00:40):
ah yes, i thought that was obvious from my "actual FHIR resources would be even better".
Jose Costa Teixeira (Nov 09 2020 at 11:04):
@Rik Smithies any discussions on whether to propose alternate resource or not - here please.
Jose Costa Teixeira (Dec 14 2020 at 18:33):
So, I still have a few further simplifications to do, but I've merged the resources into a single one.
As expected, there was a lot of overlapping attributes, so the result is not a huge resource, - and there was no need to normalize the resource attributes.
Jose Costa Teixeira (Dec 14 2020 at 18:36):
I also "cleaned up" the resource attributes a bit. For example Ingredient, which I think should be an attribute, and not a resource type , if it is not something that exists on its own - and it doesn't seem complicated now.
This reduces the number of resource types, but especially the complexity with the nesting/contained for populating some attributes, or for other concepts. IDMP has 3 medication concepts, but IIRC the australians have 7 notable concepts for medication.
Finally, I defined standard profiles for the 3 IDMP concepts. This is just to demonstrate that the resource type is reusable and profilable. So when other countries need to apply their conepts (or when IDMP changes), we can just profile instead of changing FHIR, or having several contained resources just to "borrow" one attribute.
Jose Costa Teixeira (Dec 14 2020 at 18:38):
I still want to add some attributes from the Product pattern - namely a .quantity. But this first phase did confirm to me that it is possible / cleaner to have one resource that is profiled into the 3 IDMP concepts, instead of defining core resources that mimic the IDMP product split (which has some ambiguity -arguably because of the way the EU works)
Jean Duteau (Dec 14 2020 at 19:38):
is there some way for people other than yourself to see this merge and provide feedback?
Jose Costa Teixeira (Dec 14 2020 at 19:52):
(sorry, had to go away)
I did not merge yet, I have a PR - I would indeed like feedback because I've reached "my" 80% of things that take 20% of the input/effort.
http://build.fhir.org/branches/costateixeira-product/medicationdefinition.html
Jean Duteau (Dec 14 2020 at 19:58):
how do you want feedback? on your PR? via email?
Jean Duteau (Dec 14 2020 at 20:02):
i'll also note that it's a bit hard to compare because you've change the order of some of the elements and you still have references to the "old" resources, so I can't tell if you mean for all of those references to be changed to MedicationDefinition or whether to specific profiles of the resource? And the resource profiles seem too light. As an example, the IDMP-MedicinalProduct profile only removes three attributes when I would have expected to remove a bunch more as well as having some slicing on others.
Jose Costa Teixeira (Dec 14 2020 at 20:03):
Here? Or another stream just to focus on feedback.
Jean Duteau (Dec 14 2020 at 20:03):
no, i don't want to provide feedback in zulip
Jose Costa Teixeira (Dec 14 2020 at 20:03):
- Remove references to old resources (D'oh!)
Jose Costa Teixeira (Dec 14 2020 at 20:06):
ok. I don't know what is best. You could add issues in my fork?
https://github.com/costateixeira/fhir/issues
Jean Duteau (Dec 14 2020 at 20:07):
yes, I'm going to do that
Jose Costa Teixeira (Dec 14 2020 at 20:07):
I appreciate the feedback.
Yes, the profiles are too light (took me a while to get them there, and I just wanted a placeholder - I'd want to ask for IDMP experts to help there)
Jose Costa Teixeira (Dec 14 2020 at 20:08):
I'd like to add other profiles though
Jose Costa Teixeira (Dec 14 2020 at 20:09):
this is why I start this now - I've done much of what I could do on my own just to get things going.
Jean Duteau (Dec 14 2020 at 20:10):
the problem is that without the profiles being more complete, it will be extremely hard to see if this is equivalent to the existing resources and if implementers who are using the existing resources can switch to using the profiles
Jose Costa Teixeira (Dec 15 2020 at 13:48):
I will see if the profiles have all the attributes that were in the resources - they should, but I may left something out, or it is implicit and not clear.
Last updated: Apr 12 2022 at 19:14 UTC
