FHIR Chat · Buggy codesystem · implementers

Stream: implementers

Topic: Buggy codesystem

Jens Villadsen (Oct 07 2021 at 12:08):

The codesystem on https://terminology.hl7.org/2.1.0/CodeSystem-v2-0203.html for identifierType contains the code NNxxx with the definition National Person Identifier where the xxx is the ISO table 3166 3-character (alphabetic) country code - that is sort of non-computable and cannot be verified by the validators since the validation set is not really a computable part of the codesystem

Lloyd McKenzie (Oct 07 2021 at 13:29):

@Rob Hausam

Rob Hausam (Oct 07 2021 at 13:55):

@Jens Villadsen Yes - "sort of non-computable" is rather an understatement! :) This kind of shorthand template expression (not an actual code value!) appears fairly frequently in the V2 tables. We went through all of this and should have cleaned all of it up in the V2 Tables Project in Vocabulary WG a while back. I thought the cleaned up versions are what went into v2.9 and ultimately also in THO, but apparently I'm recalling that incompletely or incorrectly, as that's obviously not true in this case (maybe it could have just been missed?). I'm pinging @Ted Klein for his recollection and thoughts about what we should do to address it now.

Ted Klein (Oct 07 2021 at 16:12):

Sigh. I have been trying to get the V2 group to fix this for YEARS. My two proposed solutions were rejected. If someone wants to put in a UTG ticket and we get the community to weigh in on Consensus Review maybe they can be embarrassed into adopting a fix. This being represented as a code because people are either too lazy to enumerate and put in the pattern codes, or just put it in the code system description and as implementers to actually RTFM, needs to be decided and done. Leaving it like this for decades is just idiocy. BTW several code V2 systems have a code value of "..." (ellipsis) for similar reasons. It was removed and the V2 management group insisted that it be brought back. Sigh.

Ted Klein (Oct 07 2021 at 16:14):

@Jens Villadsen @Rob Hausam @Lloyd McKenzie We have the means to just fix it through the UTG process. At this point I would recommend we just do it, or perhaps ask TSMG to tell us to just do it, and deal with the V2 Mgt group kvetching.

Ted Klein (Oct 07 2021 at 16:19):

This particular one in table 0203 was perhaps missed when we cleaned up the old "HL7nnnn" entry with was basically the same kind of issue.

Jens Villadsen (Oct 07 2021 at 17:27):

@Ted Klein I'm in for whatever it takes to fix this. Do you need a JIRA from me or anything else?

Ted Klein (Oct 08 2021 at 12:43):

@Jens Villadsen Yes, a Jira ticket - but not the ones you are used to putting in for FHIR it must be a ticket in the UTG ( Jira UP project). Take a look at the information for Submitting Change Requests to HL7 terminology at https://confluence.hl7.org/display/VMAH/How+To+Submit+a+UTG+Change+Proposal. Things are all done through what are called 'UTG Proposals'. For a more complete overview of how we are now maintaining vocabulary content in HL7, see the pages at https://confluence.hl7.org/display/VMAH/Vocabulary+Maintenance+at+HL7. You will have to submit a request to be a Submitter (I process those). Right now, unless special permission given by TSC, a Submitter must be an HL7 member in the HL7 member database. There are slightly different rules for members of HL7 Affiliates.

Jens Villadsen (Oct 08 2021 at 12:46):

Im chair of HL7 DK so Im a member

Ted Klein (Oct 08 2021 at 12:54):

ROTFL!!

Jens Villadsen (Oct 09 2021 at 09:44):

@Ted Klein - here you go -> https://jira.hl7.org/browse/UP-242. For the record, I've created this as a bug and not as a Change Request, as it is a bug according to my own terminology ;)

Jens Villadsen (Oct 09 2021 at 09:45):

And I've assigned the bug to you

Ted Klein (Oct 09 2021 at 12:53):

@Jens Villadsen As this is a request to change the vocabulary content, it is a change request. Sorry it is not clear what a 'bug' issue is; that is intended when the UTG workflow screens and process fail in some way. It is scheduled to be removed as an issue type as we now have a different Jira project - HSCR - for the software change requests when bugs and deficiencies are found.

Ted Klein (Oct 09 2021 at 12:57):

Right now it is in a 'Dead End' state as we have no process for dealing with content issues that are entered as a Bug. Thank you for pointing out that the Issue Type 'Bug' is confusing, improper, and should be removed as its very existence is, in face, a bug. @Jessica Bota @Joshua Procious Let us get this removed asap if we can.

Ted Klein (Oct 09 2021 at 13:00):

@Jens Villadsen As far as the content change to the v2 table content itself goes, you have two choices: to create a UP ticket as a Change Request and include a BitBucket branch with the suggested/requested technical change to the XML content through the Draft A proposal function, or just create it with a Description asking that it be fixed and sent it to Waiting For Input with the Report A Problem transition. The problem with that is we still do not have any HL7 process to get these fixed, as no HL7 resources are dedicated to or funded for content correction. The only things assigned to me that get dealt with are software issues ad Jira tooling issues/

Jens Villadsen (Oct 10 2021 at 11:56):

@Ted Klein its not a semantical change, it's syntax, so I'll still consider it a bug. Anyways, the reason why I looked at it in the first place is because I wanted a type for my identifer - in HL7 FHIR, not HL7 v2 so I looked at https://www.hl7.org/fhir/datatypes.html#Identifier and found the valueset type extensible bound to https://www.hl7.org/fhir/valueset-identifier-type.html but not of the values in the valueset was the best fit for my case, so I naturally looked at the backing codesystem and found NNxxx, which at a semantic level fit my case. As such I don't see this as being bound to v2 only - it also affects FHIR, IMHO.

I'm willing to do my share and submit a new ticket as a Change Request with a branch with the enriched Codesystem. Where's the repo located?

Ted Klein (Oct 10 2021 at 15:09):

Thanks. All of the HL7 terminology, whether it was originally for V2 or CDA or whatever, will eventually be used in FHIR IMHO. The labeling of it as v2 is really where it was imported from when we started THO/UTG a couple years ago.

Ted Klein (Oct 10 2021 at 15:13):

You will need to request Submitter permissions from the Confluence form on the pages describing Submitting a Change Request, and then clone a local copy from the Bitbucket master. The xml file for the V2 code system underlying the table 0203 content is at .../input/sourceOfTruth/v2/codeSystems/cs-v2-0203.xml (the FHIR CodeSystem resource holding the code definitions). The documentation is pretty good, if you get stuck I can help, or @Jessica Bota (new incoming Vocabulary WG cochair).

Ted Klein (Oct 10 2021 at 15:51):

https://confluence.hl7.org/display/VMAH/How+To+Submit+a+UTG+Change+Proposal

Lloyd McKenzie (Oct 10 2021 at 16:44):

@Jens Villadsen Note that "extensible" means that if any of the codes apply (even if they don't provide the level of specificity you might like), you must use one of the provided codes. (You are however free to send additional codings as translations with more or less specificity in additional to the mandated coding.)

Jens Villadsen (Oct 10 2021 at 20:41):

@Lloyd McKenzie I know. I do however find that the codesystem needs to be fixed, regardless of the binding being extensible or not

Jens Villadsen (Oct 10 2021 at 20:52):

@Ted Klein you do release that this will expand the codesystem with a factor of 3, right?

Ted Klein (Oct 10 2021 at 20:59):

That is the main reason the v2 folks declined to do it - when the code system was a published in a paper pdf document, this matters. As a web page...not so much. Take a look at the page for the expansion of the IPS value set - after 1000 codes the Publisher says it won't print more of them. If you can do it, wonderful IMHO. But as a change request for all non-ballot-bound code systems and value sets are subject to Consensus Review, the community may feel otherwise. But I would MUCH rather have something complete and processable regardless if folks find it obnoxiously large.

Jens Villadsen (Oct 10 2021 at 20:59):

:+1:

Jens Villadsen (Oct 10 2021 at 21:02):

@Ted Klein does the value of the concept Id's bear any special value in this partiuclar codesystem?

Jens Villadsen (Oct 11 2021 at 20:30):

@Ted Klein here you are: https://bitbucket.hl7.org/projects/UTG/repos/utg/pull-requests/4/overview

Ted Klein (Oct 11 2021 at 22:04):

@Jens Villadsen You need to create a UP ticket and that branch need to be included in it. Did you look at the instructions for Submitting a Change Request? @Jessica Bota did we ever document how to create a UP ticket where the BitBucket branch may have been created first, and outside of the ticket creation process?

Jens Villadsen (Oct 12 2021 at 06:20):

@Ted Klein now I have: https://bitbucket.hl7.org/projects/UTG/repos/utg/pull-requests/5/overview

Jens Villadsen (Oct 12 2021 at 10:00):

(meaning that I've renamed the branch, pushed it, removed the old one, created a jira ticket, and linked the jira ticket to the branch)

Ted Klein (Oct 12 2021 at 11:58):

ok you are almost there - you need to transition it to Draft state, make your changes to the resources (which looks like you may have done), commit and push them to the BitBucket branch. If you do local IG builds, then build the IG and see it looks ok. If you do not then Submit the proposal, and the UTG process will build the IG and check for errors. If a problem, the ticket will go back to Draft state and you will be notified. If ok, then it is part of the UTG machine and goes through the states as documented until done. So you need to move the ticket through Draft and Submit.

Jens Villadsen (Oct 12 2021 at 13:52):

@Ted Klein how? Do I have permissions to do that?

Jessica Bota (Oct 12 2021 at 14:18):

@Ted Klein , no we do not have a documented process for that. Last I recall, having a branch named differently than the auto-generated branch name was causing issues in the proposal. Happy to discuss and document if there is a repeatable process.

Jens Villadsen (Oct 12 2021 at 14:39):

I can rename the branch to whatever you guys need

Ted Klein (Oct 12 2021 at 18:58):

@Jens Villadsen the reason we ask people to follow exactly the process outlined in the documentation is because we have Jira scripts and automation to do and help with various parts of the workflow. So it is a pain if you are already familiar with Git and BitBucket and know what you are doing and seems nothing but trouble. But is is needed, as syntactic elements of various created fields are used later in the process for Jira scripts, validation, voting, etc. That having been said...I am not sure how to figure out what the automatically script-created name of the proposal that would have been created would be. But we can attempt to push it through and see if something fails in the workflow...as instructed in the documentation, you do not automatically have permission to Submit a proposal. This gets given by filling out the Confluence Form to request Submitter permissions on page https://confluence.hl7.org/display/VMAH/Get+Access+to+Jira+UTG+Proposal+Project Right now that is manually handled as the Jira scripts are not yet debugged; in the future, persons can ONLY submit proposals by using this form, as it will be automated. In the interest of time I went ahead and processed you as if you had submitted form just now, but please submit it anyway, as data linked to the form macros is used for audit for Submitter requests, etc. Now you should see two buttons on your ticket: Draft A Proposal, and Waiting for Input. Since you already have designed the requested change, you should NOT click Waiting For Input (this is for if folks don't have all the information needed to create the XML for the changes). Then click Draft A Proposal, and you should see a button to Submit it. That takes your BitBucket branch content and validates it, processes it, does all kinds of scripting and processing, and then moves it to Consensus Review for community approval as a V2 proposal (which means persons identified by the V2 management group must be aware of the changes and weigh in on the requested change, along with others in the implementation and standards-writing HL7 community). This is done as part of moving all non-structural terminology used in HL7 IGs out of ballot update cycles and into this new process for validation and publishing. Kind of a lightweight balloting in some ways. @Jessica Bota did I cover everything here for Jens? Let me know if you run into further problems.

Grahame Grieve (Oct 12 2021 at 19:35):

you know, @Jens Villadsen @Ted Klein I could work around this in the terminology server with some special logic when validating, since any resolution of the definitions is likely to be messy. Ted, do we have a list of these things somewhere?

Ted Klein (Oct 13 2021 at 00:25):

@Grahame Grieve The issue is that many implementers just blindly import the entries from <code> into their servers never looking at the content. I prefer leaving a gremlin to force the TSMG and management groups to actually fix the issue. We have had an outstanding ticket to fix the issue in table 0396 for over a year...and for at least four years before that we have had complaints from implementers of v2 tables that entries like "HL7nnnn" and "..." were for human readers of pdf documents but they were shown as code entries and dutifully imported by techies. When we converted to machine readable from PDF the problem became worse. IMHO we need some kind of indicator or element or extension which can hold syntax definitions (e.g. hold BNF for instance) for those code systems which have grammars that permit any code consistent with the grammar to be conformant. Such as IANA media types. BCP-47. UCUM, for that matter... If we were not so busy doing other things, we would figure out and implement a general solution to this, which was explored in Vocabulary with David Markwell over 10 years ago.

Grahame Grieve (Oct 13 2021 at 00:39):

well, we could do this: mark that those code systems have a grammar, and then user some extension to indicate what the grammar is for those elements, and then code up the renderers and validators to understand the codes

Jens Villadsen (Oct 13 2021 at 09:42):

I don't think we need special logic in special places. We need transparent, operational codesystems and we need to fix what is broken

Grahame Grieve (Oct 13 2021 at 10:26):

don't like grammar, huh?

Jens Villadsen (Oct 13 2021 at 11:38):

grammar is fine, as long as it is computable

Ted Klein (Oct 13 2021 at 11:58):

@Jens Villadsen Not a problem with a system where the grammar allows only a few hundred codes, which is a simple matter of a bit of scripting to create them as pre-coordinated codes. Much harder with a grammar where the numbers are not numerable (mediatypes, for instance), and may be millions. The issue with the "HL7nnnn" requires about 700 new codes to be added.

Ted Klein (Oct 13 2021 at 16:22):

Jens, did you assign UP-243 to me? You should not have been able to do that, there must be a hitherto undiscovered bug in the workflow. Assignee only should get assigned when entering Proposal Draft, otherwise in Environment Setup and Wating for Input, there should be only a Reporter. We have entered a change request in the UTG Jira bug reporting system to fix this. My curator workflow does not allow me to move the ticket through the workflow so by assigning it to me, you have essentially moved it into a dead end; nothing further will happen on the ticket. You need to reassign it to yourself and move it through Draft A Proposal and Submit as described in the instructions. @Joshua Procious Jess and I put in an HSCR ticket to address this - it is a big problem with our workflow.

Grahame Grieve (Oct 13 2021 at 19:38):

grammar is fine, as long as it is computable

which existing grammar would you nominate as computable?

Jens Villadsen (Oct 13 2021 at 21:16):

@Ted Klein - yep I assigned it to you -and @Joshua Procious reassigned it back to me ;)

Jens Villadsen (Oct 13 2021 at 21:24):

@Ted Klein I'm sorry but you need to carve it out in stone for me as I do not understand what I'm missing here. I've made a change request as mentioned on Draft a Proposal. I've made sure my branch name is alligned with the change and Jira even shows this. What is it that I haven't done correctly? - followup question: why isn't my branch to be found here: https://build.fhir.org/ig/HL7/UTG/branches/

Jens Villadsen (Oct 13 2021 at 21:26):

I've even made the pull request and assigned you as reviewer

Ted Klein (Oct 13 2021 at 21:47):

Ah ok - the good thing is that you are showing where our documentation is insufficient. The process is: you create the ticket and document what is needed. Then you have a CHOICE: if you know what needs to be done, you Draft A Proposal, which involves creating and linking the branch. Then you MUST get an HL7 workgroup sponsor for the change, who must APPROVE your designed changes. In your case, I think it can either be the International Council, or more rightly, the V2 Management group OR the INM (Infrastructure and Messaging) workgroup, which deals with things like this in V2. They must APPROVE the change request, and the link to their minutes showing the approval decision must be put in the ticket. Then you Submit, which sends it into the Curator workflow to run a FHIR build and validation, and check for errors in the context of all the content in the ci build. If it builds cleanly (zero errors from the IG Publisher) then it gets transitioned to Consensus Review for tracked and audited voting by the team of Vocabulary Reviewers. For Pro Forma proposals, it bypasses the voting as those are usually decided in ballot reconciliation, and the vote to approve is linked from there. Then it goes to a QA review.

Ted Klein (Oct 13 2021 at 21:49):

So for you, you need to click Draft a Proposal, add INM as sponsor and send the link to those cochairs asking that its approval be place on the agenda for their next conference call. Then wait until they approve it (or change or modify it if they demand for approval), and then click Submit. After that is the mostly automatic in the workflow (unless questions are asked in the Comments, which you need to respond to).

Ted Klein (Oct 13 2021 at 21:50):

It is a pretty formal process now, as you see.

Patrick Werner (Oct 14 2021 at 08:42):

Grahame Grieve said:

well, we could do this: mark that those code systems have a grammar, and then user some extension to indicate what the grammar is for those elements, and then code up the renderers and validators to understand the codes

I really like this idea.

Ted Klein (Oct 14 2021 at 13:48):

I am very much in support of this. But if we want to do it well and comprehensively, we need a way to define the grammars in a machine processable wy in a single place so the all servers and processing handles it the same way. Couple ways to do this, but none are trivial.

Jens Villadsen (Oct 14 2021 at 18:46):

@Ted Klein should we schedule a short meeting? I still fail to understand what I'm missing here:

The process is: you create the ticket and document what is needed

Done, thats https://jira.hl7.org/browse/UP-243

Then you MUST get an HL7 workgroup sponsor for the change, who must APPROVE your designed changes

Well ... ain't that the reason that we have and use pull requests for. It is right here: https://bitbucket.hl7.org/projects/UTG/repos/utg/pull-requests/5/overview

Then you Submit, which sends it into the Curator workflow to run a FHIR build and validation, and check for errors in the context of all the content in the ci build.

Wait what? What is it that I haven't submitted?

Jens Villadsen (Oct 14 2021 at 18:51):

I've now added Craig Newman (V2 Management Group), Peter Jordan (IC) and Anthony Julian (InM) as reviewers on the PR. Anyone of them can approve the PR and anyone of them can decline it

Grahame Grieve (Oct 14 2021 at 19:07):

we need a way to define the grammars in a machine processable wy in a single place so the all servers and processing handles it the same way

I don't really believe in that. a meta-language for grammars... too much. Even for v2. But do we have a list of all the v2 codes that work like this? Maybe it's acheivable just for those... but I'm still not sure it's worth it

Grahame Grieve (Oct 14 2021 at 19:08):

that's why I propose to document them in narrative and just identify them computably

Jens Villadsen (Oct 14 2021 at 19:14):

@Ted Klein - you might wanna have an extra more careful look at the bitbucket authorization stuff as I seems like I can just bypass all this and just press "merge" - thereby bypassing the ENTIRE process.

Screenshot-2021-10-14-at-21.11.09.png Screenshot 2021-10-14 at 21.11.09

Ted Klein (Oct 15 2021 at 01:05):

@Grahame Grieve agree that will achieve something for the less than 5% of things having this problem (maybe even fewer) with less Tham 5% (maybe less) of the required effort.

Ted Klein (Oct 15 2021 at 01:09):

@Jens Villadsen ok - I think I see what you do not understand. In UTG BItBucket is ONLY a convenient place for Submitters to assemble their content. Nothing in BitBucket goes into the THO release until lots of other tooling run by the curator and the consensus and notification process of and to the HL7 Reviewer pool gets done, then audit trail history records are created and validated, and only THEN does it get applied against the source of truth for the ci build - which is NOT built from the BitBucket content. The master of the BitBucket content is OVERWRITTEN on every ci build update. So if you think you want to be clever and bypass all this stuff that is unknown to you, all your work will simply be overwritten and lost.

Ted Klein (Oct 15 2021 at 01:09):

I think you do not want that.

Ted Klein (Oct 15 2021 at 01:11):

The branch in BitBucket is NOT manually pulled to process the changes; tooling does that, managed through the JIRA process. If you do not want to run the Jira workflow, then we have no facility to get your requested content into THO. Full Stop.

Ted Klein (Oct 15 2021 at 01:13):

On the top of the Jira ticket screen for your ticket there should be a button labeled "Draft a Proposal". If you do not trigger this, your changes will never get looked at or processed by anyone, and they will be overwritten as BitBucket is a scratchpad temporary environment.

Ted Klein (Oct 15 2021 at 01:14):

Once in Draft, you will see a button "Submit" on the top of the ticket screen. This is what starts the machinery to process the changes. If you do not trigger this workflow, the ticket will stay there forever, and eventually it will be deleted probably.

Ted Klein (Oct 15 2021 at 01:16):

The CTO and TSC chair at HL7 have directed that all change requests for any HL7 Terminology published in THO be reviewed and approved by an HL7 workgroup before Submit to UTG for incorporation. If a Submitter feels circumstances warrant it, a petition directly to the TSC chair can be made to waive this.

Ted Klein (Oct 15 2021 at 01:20):

The key thing you seem to be missing is that BitBucket is just a temporary scratchpad environment to create the changes in context; all the real works happens in Jira, and the processes triggered through Jira.

Ted Klein (Oct 15 2021 at 01:23):

Screen-Shot-2021-10-14-at-9.22.26-PM.png Screen Shot 2021-10-14 at 9.22.26 PM.png

Ted Klein (Oct 15 2021 at 01:25):

Note that on my screen there I have a bunch of admin functions on top and in the dropdown that you will not see. What you WILL see is Draft A Proposal, which you must execute to start the process.

Grahame Grieve (Oct 15 2021 at 02:15):

well, @Ted Klein can we get a full list easily?

Ted Klein (Oct 15 2021 at 02:36):

no idea how. I know of the one in table 0396, and the one Jens pointed out in 0203. I know there are others, but other than eyeballing the content of each one, I have no clue how to recognize it. Any <code> values that are an ellipsis ("...") would be an indication of one, but not an absolute signpost.

Ted Klein (Oct 15 2021 at 02:37):

I think one of those used in the v2 TQ datatype for repeat patterns might be one...

Grahame Grieve (Oct 15 2021 at 03:04):

my list:

Grahame Grieve (Oct 15 2021 at 03:04):

#0354
 RTB_Knn : Message structure
 QBP_Qnn : Message structure

#0396
 IBTnnnn: ISBT 128 codes where nnnn  specifies a specific table within ISBT 128
 HL7nnnn: Health Level Seven defined table of codes, where nnnn is the HL7 table number
 ISOnnnn: ISO Defined Codes where nnnn is the ISO table number.
 X12Dennnn: value="ASC X12 Code List nnnn

#0203
 NNxxx: National Person Identifier where the xxx is the ISO table 3166 3-character (alphabetic) country code

#0066
 ...:  see chapter 6

#0200
 ...: No suggested values defined

#0291
 ...: Source RFC 2046

#0359
 2 ...: For ranked secondary diagnoses
 ...: No suggested values defined

#0365
 ...: (null) No state change

#0366
 ...: (null) No state change

#0367
 ...: (null) No level change

#0418
 ...: No suggested values defined

#0466
 ...: No suggested values defined

#0487
 ...: No suggested values defined

#0544
 ...: No suggested values defined

Grahame Grieve (Oct 15 2021 at 03:05):

in all cases, nnnn is replaced with a code from a value set. So we could define a value set that extends the code by replacing the suffix (and maybe standardise the suffix). This would work fine for the nn/xx ones. I don't think any of the ... are controlled grammars that this logic applies to - they're all something else

Ted Klein (Oct 15 2021 at 11:40):

without delving into seeing if that covers all I think you have them - certainly the worst offenders. That is a good machine processable solution...

Jens Villadsen (Oct 15 2021 at 13:01):

@Ted Klein thanks for bearing with me. I've found the button for "Draft a proposal"

Jens Villadsen (Oct 15 2021 at 13:01):

image.png

Jens Villadsen (Oct 15 2021 at 13:02):

in regards to the sponsor approval date. Should I reach out to the sponsor here beforehand of pressing submit?

Jens Villadsen (Oct 15 2021 at 13:04):

(and ... I do have a lot of feedback for your flow if you're interested. From a software dev perspective, it seems funky that you use the bitbucket repo as just a scratchpad and not the actual place to deal with changes and change proposals, using pull requests and so on - the current process ain't that friendly for people that actually brings the changesets as part of the jira ticket).

Ted Klein (Oct 15 2021 at 13:20):

it is to allow the entire community free access to work on their proposals, but to completely protect the actual HL7 source of truth where only a couple of admins have access to it. And Submit will give you an error without a Sponsor and Approval date.

Ted Klein (Oct 15 2021 at 13:22):

UTG was designed for primarily non-development people who used to submit change proposals as vague and ambiguous Word documents, then complain when the dev team implemented what they interpreted which was different than what the non-techie wrote. Now the Submitter creates and can build exactly what they want, and all the HL7 tech staff do is create the audit entries and merge it to the main Git repo.

Ted Klein (Oct 15 2021 at 13:23):

HL7 has ZERO funded tech resources for content development work.

Jens Villadsen (Oct 15 2021 at 15:16):

That can be guarded on the bitbucket repo as well. You dont need a second repo for that

Jens Villadsen (Oct 15 2021 at 15:23):

@Ted Klein - https://confluence.atlassian.com/bitbucketserver050/using-branch-permissions-913474668.html

Grahame Grieve (Oct 15 2021 at 19:46):

see https://jira.hl7.org/browse/UP-244

Ted Klein (Oct 15 2021 at 20:03):

@Jens Villadsen Correct. But three years ago when this was a fully explored and the system architected, the decision was made to use separate repos. You may want to look over the architecture documents for UTG/THO.

Jens Villadsen (Oct 16 2021 at 09:29):

@Ted Klein - but anything could be changed, right? - I mean if the actual source of truth is here (right?): https://github.com/HL7/UTG - I might as well do the pull request there and save someone the work, and then link to that PR in the jira.

Ted Klein (Oct 16 2021 at 18:51):

if you do that, your branch will be ignored. BitBucket is used as the intermediary scratchpad location for builds and merges and implementing. Your content will become stale rapidly, and be overwritten or erased in a relatively short period of time.

Last updated: Apr 12 2022 at 19:14 UTC