Stream: terminology
Topic: Process for adding a code to Consent PolicyRule ?
Oliver Egger (Jan 27 2021 at 16:39):
We would like to add a code to the Consent PolicyRule Codes ValueSet and CodeSystem for our swiss epr system (ch-epr) like there is a code for the austrian epr system (at-elga). Which process do we have to follow? Do we have to contact the Workgroup which is mentioned as the Committee Community Based Collaborative Care or is there another way?
John Moehrke (Jan 27 2021 at 16:45):
@David Pyke -- excellent question @Oliver Egger .. I am confused too on the new terminology process...
a more fundamental question I have is, why do you think your code needs to be managed in the hl7 terminology? Wouldn't regional codes be better managed in that region? I do understand that data leaves regions, but when it leaves a policy decision/action is made about that leaving act.
Oliver Egger (Jan 27 2021 at 16:49):
@John Moehrke good point, it's is more a national code. however since our neighbours have it also inside i thought the code might better live there than to manage our own code system just for a simple code.
Frank Oemig (Jan 27 2021 at 16:50):
UTG!?
David Pyke (Jan 27 2021 at 16:50):
Yes, but how does one UTG?
David Pyke (Jan 27 2021 at 16:51):
Oliver, that codeset is Extensible, you can simply use your own code as needed
Frank Oemig (Jan 27 2021 at 16:51):
That's a process via confluence. Need to look for the URL
John Moehrke (Jan 27 2021 at 16:52):
so @Oliver Egger that argues for us to have possibly a much more simple way for all the regions of the glob to register their consent policy identifiers... righ? To force them thru UTG seems heavy and a problem.
Frank Oemig (Jan 27 2021 at 16:52):
Identifiers or codes?
John Moehrke (Jan 27 2021 at 16:53):
these policy codes/identifiers should be more strict than typical vocabulary in that they need to have pointers (narrative only?) to the meaning of the policy code/identifier.
John Moehrke (Jan 27 2021 at 16:53):
Frank Oemig said:
Identifiers or codes?
reality is that a code is a form of identifier...
John Moehrke (Jan 27 2021 at 16:54):
especially when the code is a representation of a regions regulation
Frank Oemig (Jan 27 2021 at 16:55):
No, a code is for concept, an identifier is an instance. But both belong to a system
Frank Oemig (Jan 27 2021 at 16:56):
The machinery around is similar
Oliver Egger (Jan 27 2021 at 16:58):
David Pyke said:
Oliver, that codeset is Extensible, you can simply use your own code as needed
yes, that would be the other option if it cannot live in the hl7 terminology.
Robert McClure (Jan 27 2021 at 22:41):
@Oliver Egger I agree with you that UTG is the best solution so the code is easily found and utilized by all FHIR implementations. I understand that some folks think UTG is "heavyweight" but it's funny that no one complains that they have to craft FHIR IGs to make FHIR guides, yet the ground is wet with angst about using FHIR to create FHIR terminology. If you want to add the code, you can create a UTG proposal and it should move on through. VOcab Maintenance at HL7 can get you up to speed. @Jessica Snell
Oliver Egger (Jan 28 2021 at 12:42):
@Robert McClure thanks for this helpful information, I created the proposal and will install now the tooling to provide the code information.
Carol Macumber (Jan 28 2021 at 14:46):
@Oliver Egger , if you need assistance, please do reach out and the UTG team will help you get set up. We also appreciate any feedback you have on the process as we continue to note opportunities for improvement.
Oliver Egger (Jan 28 2021 at 20:51):
thanks @Carol Macumber . The process is very nice documented, i had only a minor issue with the tooling (FHIR Toolkit does not startup on OSX) and the IGPublisher needed a bit more memory for the UTG than the default memory setting.
Oliver Egger (Mar 28 2021 at 19:54):
our change proposal for adding a new code to the Consent PolicyRule CodeSystem/ValueSet is blocked by UPSM-10 Parameter Setting. Is there anything we can do to "unblock" our change proposal? we have our swiss ballot almost through but I would not like to include not yet approved codes, so any feedback how we can proceed or what we need to further provide with our change proposal would be very helpful.
Robert McClure (Apr 09 2021 at 00:00):
@Oliver Egger I don't think you have set up a proposal yet have you? I don't see evidence in the proposal that you have created the changes. The "blocker" is not having created the actual technical material. @Jessica Snell
Marc Duteau (Apr 09 2021 at 05:06):
@Jessica Snell can correct me if I’m wrong but that “blocker” is the way that the system for voting is managed as I understand it. Once the proposal is set up and submitted it will enter the consensus review stage and once it gets the votes it needs (including from the relevant OSG voters) it will pass and be “unblocked”.
Oliver Egger (Apr 09 2021 at 06:13):
@Robert McClure thank you for the feedback. the proposal is setup and I made the changes in a branch as described in Submitting Change Proposals for Advanced and Experienced IG Developers. What I did not yet do was to create a PullRequest for the branch to the master (it was not mentioned in the process above), I added this now. @Jessica Snell is there anything else I need to do that it gets to the consensus review stage as @Marc Duteau mentioned?
Jessica Bota (Apr 09 2021 at 13:22):
@Oliver Egger , to be honest I am not sure why/if the PullRequest is needed since I am not a developer. The pieces missing seem to be to commit the changes (I do not see one) and to 'Submit' the proposal using that button at the top of the proposal. Once that is done, it will be processed for Consensus Review. I took a quick look at your proposal and you should also increment the version number before submitting since adding a new code is a major change. That versioning policy is here for future reference: https://confluence.hl7.org/display/VOC/Documented+Execution+of+UTG+Versioning
CC: @Robert McClure @Marc Duteau
Jessica Bota (Apr 09 2021 at 13:24):
@Oliver Egger another piece I missed above is the UPSM-10 'blocker'. This ticket is connected to allow us to apply voting parameters to the ticket. It is not actually a blocker. Perhaps we can change how that is represented.
Oliver Egger (Apr 09 2021 at 13:58):
@Jessica Snell thanks a lot for the feedback! I missed clicking the 'Submit' proposal button. This is not described as a necessary step in Create a Proposal, could this be updated (I can also update it if you agree)? I updated the PR with a new version for the CodeSystem, so I hope now the proposal can get to consensus review stage :pray:
Robert McClure (Apr 14 2021 at 03:00):
@John Moehrke @Frank Oemig Please review and weigh in, and vote, for https://jira.hl7.org/browse/UP-163
John Moehrke (Apr 14 2021 at 12:22):
I see the new code in the build.. but there is no provenance. the pull-request mentioned in the CR does not identify Oliver's changes
Oliver Egger (Apr 14 2021 at 12:31):
@John Moehrke you can see the PR here
John Moehrke (Apr 14 2021 at 12:34):
thanks, that shows you adding the code. The PR in the jira ticket does not.
Oliver Egger (Apr 14 2021 at 12:38):
in the jira ticket you have on the right a column with a development entry, and then you can link on the open pr, click one more in the popup and in there in the diff tab you end up the link I added :grinning:
John Moehrke (Apr 14 2021 at 12:54):
I did do that, but that did not show me the insertion of the code, just the changing of the date and version.
John Moehrke (Apr 14 2021 at 12:55):
ah, the key was Overview tab vs Diff tab
John Moehrke (Apr 14 2021 at 12:55):
bitbucket is not normal
John Moehrke (Apr 14 2021 at 13:07):
@Robert McClure and @Ted Klein should the history be added as part of the process? Or is this added later?
Ted Klein (Apr 14 2021 at 18:13):
@Oliver Egger The reason you see it blocked by UPSM-10 is that is part of the Jira 'plumbing' we use to do the voting displays, computations, and decisions to move the the next state. All the code for this is driven from the parameters and settings and so forth in the UPSN-10 ticket. That is normal; once this passes Consensus Review you will see it will become blocked by the set of ticket structures in UPSM to control the implementing of an approved proposal. We probably need to document this better so folks who are very detail oriented like yourself do not get confused by what they see.
Ted Klein (Apr 14 2021 at 18:18):
@John Moehrke This is GREAT feedback; we will put into our queue improvement in some of the detailed guidance so folk can easily find what they need to look up. The history Provenance structure is added AFTER the proposal passes Consensus Review - during the implementation process. It is not uncommon that some additional Provenance information needs adding based on the underlying source of truth having changed from implemented proposals while the one is question is in Consensus Review state. Things are 'final' only after the vote is passed, and at that time the History tracking Provenance resource entry is added as part of the implementing into the ci build Git source of truth and updating of BitBucket master branch operations.
Last updated: Apr 12 2022 at 19:14 UTC
