FHIR Chat · R4A Release · implementers

Stream: implementers

Topic: R4A Release

---

Grahame Grieve (Jun 03 2020 at 21:31):

Place holder for discussion to come.

Grahame Grieve (Jun 03 2020 at 22:59):

see https://chat.fhir.org/#narrow/stream/179240-Announcements/topic/Release.20R4A. This thread is for discussion about whether an interim 4A release is a good idea or not

Lloyd McKenzie (Jun 03 2020 at 23:24):

Proposed scope rules and objectives for the release are here: https://confluence.hl7.org/display/FMG/Proposed+guidance+for+R4A+Scope

Drivers for the release are:

• there are a few governmental projects that are dependent on content that is still 'draft' in R4 and waiting for an R5 release (which at this point, would be end of 2021 at the earliest) is untenable
• there are some significant limitations with the Subscription resource in R4 that implementers would like corrected
• there's a desire to inject some additional guidance into the R4 release, given its prominence in certain regulatory spaces
• it takes a while for the implementer community to coalesce around a new release and there doesn't seem to be much of a drive for R5 in the community so far (beyond the needs listed above)

Note that if we proceed with an R4A, any subsequent R5 release would be published late 2022 at the earliest.

Josh Mandel (Jun 03 2020 at 23:24):

This doesn't seem like a slam dunk good idea to me. For subscriptions in particular we already have a working plan to "backport" to r4 without needing r4 to change (@Gino Canessa has been working on this). it sounds like the other major opportunity would be around medication resources...

Lloyd McKenzie (Jun 03 2020 at 23:26):

Specifically medication regulation resources (those at the bottom-right of the resource list). The release would not touch Medication, MedicationRequest, MedicationDispense or MedicationStatement (except possibly non-substantive changes around descriptions and guidance).

Grahame Grieve (Jun 03 2020 at 23:37):

I'm not personally signed on to this - it presents a huge raft of challenges

Gino Canessa (Jun 04 2020 at 02:23):

My biggest question is what are we looking at for time frames one way or the other. If we're saying R4A would be a month or two and R5 would be a year, that is different than saying R4A would be 9 months and R5 would be 12 months.

Lloyd McKenzie (Jun 04 2020 at 03:54):

R4A would be just under a year. R5 will be 1.5 years if we skip R4A or 2.5 years if we do R4A.

Brendan Keeler (Jun 04 2020 at 05:41):

"there are a few governmental projects that are dependent on content that is still 'draft' in R4..."

HL7 2.5.1 has entered the chat

Jose Costa Teixeira (Jun 04 2020 at 06:01):

Lloyd McKenzie said:

Specifically medication regulation resources (those at the bottom-right of the resource list). The release would not touch Medication, MedicationRequest, MedicationDispense or MedicationStatement (except possibly non-substantive changes around descriptions and guidance).

I wouldn't want to rush those. We're working on a project that hopefully will bring insight on how the regulatory spaces (global, regional, national) and clinical spaces would work, and while I am happy with the progress and convergence, this seems far from stable. Pushing it out would be counterproductive IMO

Lloyd McKenzie (Jun 04 2020 at 06:26):

The intention wouldn't be normative, just FMM1

René Spronk (Jun 04 2020 at 06:41):

This feels like a very US-oriented discussion - "HL7 v2.5.1 has entered the room" indeed.
However, we have to accept that the version referenced in the current ONC/CMS rules will be the most widely implemented version for at least the next few years (in the US), so if this is a way to have a better fitting normative release for that time period, then go for it. In practice it may turn out to be a 2.5.1, i.e. ignored anywhere outside of the US, but that doesn't matter too much. The versioning principles of FHIR are solid enough to deal with this additional quirky release.

Richard Townley-O'Neill (Jun 04 2020 at 06:49):

How likely is an R4B 9 months after R4A?

Jose Costa Teixeira (Jun 04 2020 at 07:46):

The intention wouldn't be normative, just FMM1

I am convinced these resource will be drafty for a while, but there is a chance I'm wrong. And we have a big project across Europe to check that, so I would wait for a large community to validate this.
My fear is that regulators get the impression that resources are done, so they make a milestone, and push this to many member states in EU.
And then if implementers realize any gaps, it's a disproportionate effort to change things.

Jose Costa Teixeira (Jun 04 2020 at 07:50):

My area of focus / concern is specifically IDMP.

Rik Smithies (Jun 04 2020 at 08:47):

This release is very important for the Medication Definition resources ("IDMP", though it is more than that), on which a whole industry is waiting.

They have come a long way since the Level 0 versions in R4 and waiting another year til R5 puts a severe block on getting these out of draft.

We need a proper release with these in, in their FMM1 form where they have all changed name - to a large extent they don't exist at all currently. We can then have tool support and can try them out at connectathons, and fix the issues.

FHIR has never taken a position that things are too draft to publish, in case they get used. That goes against the whole spirit of FMM. Implementation to get maturity, not the other way around.

Jose Costa Teixeira (Jun 04 2020 at 09:01):

They've come a long way, I agree. I think they have a long way ahead too.
I am not sure the industry and regulators are ready for the agility that we support. @Rik Smithies are you confident that the whole spirit of FMM can be followed by the industry? Are they accepting to revise their publications as the designs need to be changed? Suppose we have to drop one of the resources - technically this is easy, but my experience tells me that the regulators will not like that change.

Jose Costa Teixeira (Jun 04 2020 at 09:08):

Projects like UNICOM could incubate the use of the resources - for which I agree the updates are welcome, the more iterations the better.
My fear is if regulators get /give the impression that the design is done.

Rik Smithies (Jun 04 2020 at 09:11):

At the moment they don't even have the resources to look at.

Jose Costa Teixeira (Jun 04 2020 at 09:14):

I agree, I am just careful with keeping the agility to change and learn from feedback - which is hard and a release can make harder.

Jose Costa Teixeira (Jun 04 2020 at 09:19):

Is it an option to do for these resources the same as is being done for Subscription?
(Rik, I understand the risk in having the latest fhir release with those resources as they are - I want updated resources too, i'm just wondering if we need a release for that)

Rik Smithies (Jun 04 2020 at 09:20):

What other way is there to get the resources out and being looked at than a release?

Jose Costa Teixeira (Jun 04 2020 at 09:21):

OTOH, there are some considerable cleanups in and around
Device
possibly some stuff around Permission (for Privacy)
Inventory
that could be also kind of urgent - do we plan to put them in a R4A as well?

Jose Costa Teixeira (Jun 04 2020 at 09:21):

Rik Smithies said:

What other way is there to get the resources out and being looked at than a release?

@Gino Canessa ?

Rik Smithies (Jun 04 2020 at 09:31):

R4A as I understand it is about releasing a group of resources (or other things) that have no real dependencies on any other part of FHIR. It is a quick win - not easy, but easier than the alternatives.

This isn't an early release of R5. It is R4 unchanged (so as to be acceptable to those locked to R4 for now, and for ease of creation), plus "standalone" new content.

It's a shame we can't have R5 early, but that shouldn't stop us going forward in these areas.

Peter Jordan (Jun 04 2020 at 09:45):

To have an informed opinion on this, I believe that some clarity is required regarding the potential scope of R4A. For example, would it be possible to include improvements to the descriptions of elements in normative resources? Many implementations are now fixed on R4 and there will be an obvious temptation for committees to try and push changes into R4A that wouldn't otherwise be available to those implementations for quite some time. An example of this might be the changes to the ConceptMap Resource that are in R5.

Rik Smithies (Jun 04 2020 at 10:10):

non-breaking changes? or "non-substantive" perhaps

Grahame Grieve (Jun 04 2020 at 11:35):

the changes to ConceptMap cannot be in scope

Jason Walonoski (Jun 04 2020 at 12:25):

If you need to make a release (to support a few resources), I would suggest a smaller highly constrained R5 instead of an R4A. It might only be semantics to some, but I think it is a big deal and will sow all sorts of confusion in the industry and among regulators and on those who are not FHIR insiders.

Rob Hausam (Jun 04 2020 at 13:28):

@Grahame Grieve Yes, my assumption was that the ConceptMap changes would not be in scope for R4A. But it also seems to me that if we need to wait 2.5 more years for the changes to arrive in an official release and we continue to use the R4 ConceptMap in the meantime, then by the time we actually get to R5 it's likely that there will no longer be any appetite for making changes like this to a conformance resource. If that's the case, then possibly the most likely outcome would be that we will roll back those updates and continue with the R4 approach and those updates will never be made? And, if we do make the R5 updates, then that would also mean that it will be considerably longer than 2.5 years before we can get the last remaining conformance resource to normative? Even if only part of that is true, it doesn't sound too good to me.

Rik Smithies (Jun 04 2020 at 13:40):

@Jason Walonoski I agree we need to name it carefully, but, for some, "R5" will have the wrong semantics.

People will stay on R4 until there is a good reason to go to R5. If R5 is just R4 and some fixes then this will be no use to anyone.

R4 people will see it as something they cannot use (because it's not called R4). And there will be no incentive to make the jump to an R5 that adds little.

Making it an R4 series means it is palatable for R4 users. And it's not just the name, it really will be pin compatible with existing R4, just with some useful extras.

I also think that having a major release of FHIR (R5) that added little would send all sorts of wrong signals about FHIR stagnating.

Jason Walonoski (Jun 04 2020 at 13:54):

I also think that having a major release of FHIR (R5) that added little would send all sorts of wrong signals about FHIR stagnating.

I see that as a sign of maturity, not stagnation.

Rik Smithies (Jun 04 2020 at 13:55):

only if we don't want FHIR to evolve and do new things. We are not done yet :-)

Rik Smithies (Jun 04 2020 at 14:05):

Perhaps the solution is to make R4A as small a deal as possible.

There is no real reason to delay R5 significantly for a point release to R4 I would say. I'm only one person, but I'm quite happy to help get it out of the door. I can't see why it would cause a year delay to R5 in itself.

Sure, if we no longer need R5, because we have all our good stuff in R4A, then no rush for R5.

But I am not hearing that, and so maybe the practical or scope related reasons to push R5 out by a year are not there.

Jose Costa Teixeira (Jun 04 2020 at 14:46):

Are we talking about a thematic / dedicated release?

Rik Smithies (Jun 04 2020 at 14:51):

R4A could be called that I suppose, as it was originally proposed. It would be full release, just with the additions being limited to certain areas.

Jean Duteau (Jun 04 2020 at 14:55):

I guess I'm missing the point of this release because it seems to me that there are a number of stakeholders who need some of the content that is currently slated for R5 to be released sooner than the current R5 plans. The MedicinalProduct resources are just one slice of that. For my work specifically, the changes to AdverseEvent are needed ASAP as well as the changes to ConceptMap. There are probably other implementers who need some other change sooner rather than later. Doesn't this tell us that we need to publish an R5?? I don't buy Rik's arguments around who will jump and who will not. Those seem to me to be arguments to never release an R5 ever unless it is a "break everything" release which can't happen.

Rik Smithies (Jun 04 2020 at 15:00):

I think the idea is that lots want some of what is in R5. But bringing all of R5 forward is not practical.

However there may be a couple of constituencies who want some things that are more or less ready to go now - and also are relatively self contained (e.g. affecting only existing Level 0 stuff, and that are not linked to from anywhere).

If it doesn't delay R5, and I don't see why it should (R5 being delayed for other reasons), why not do a low hanging fruit R4A. No one needs to lose, and some gain.

Lloyd McKenzie (Jun 04 2020 at 15:21):

As a reminder, the proposed scope for R4A is here: https://confluence.hl7.org/display/FMG/Proposed+guidance+for+R4A+Scope

The notion is that there would be NO substantive changes to anything other than the medication regulation, evidence based medicine and Subscription resources. Those were called out because both the medication regulation and EBM stuff are limited to isolated communities (99% of FHIR implementers have never touched and have no plans to touch those resources), so releasing those doesn't actually impact most implementations (in the U.S. or elsewhere). The changes to Subscription are because those who are trying to implement the R4 version are finding it broken.

This would not be a U.S.-centric release. Much of the medication regulation stuff is happening in Europe right now and EBM is global. The intention is to be able to say - for most systems - is that if you're R4 compliant, you're automatically 4A compliant. I.e. we don't have to worry about having to do inter-version conversions between R4 and R4A.

Lloyd McKenzie (Jun 04 2020 at 15:23):

R4A will absolutely delay R5 (by a year or more). Putting out any major FHIR release is a huge undertaking and any effort we put into R4A will not be put into R5. If we put R4A out by April of 2021, we'd be looking at R5 in December of 2022 rather than December of 2021.

Rik Smithies (Jun 04 2020 at 15:29):

thanks Lloyd, I appreciate that any release is a big effort but are we really saying that producing R4A, given we have R4 and we have most of R4A content now (which is why it is perhaps viable), would take at least a year? Could we break that down a little, and perhaps contrast to producing a Connectathon build (e.g. R5 preview #2)?

Jean Duteau (Jun 04 2020 at 15:33):

Okay, how would a group get additional resource changes included? Make a proposal to FMG? The changes to AdverseEvent which are needed for any system that is trying to implement seem to be in the same camp as the EBM, MedicinalProduct, and Subscription proposals.

Vassil Peytchev (Jun 04 2020 at 16:20):

Lloyd McKenzie said:

R4A will absolutely delay R5 (by a year or more). Putting out any major FHIR release is a huge undertaking and any effort we put into R4A will not be put into R5. If we put R4A out by April of 2021, we'd be looking at R5 in December of 2022 rather than December of 2021.

I think this is an opportunity to review and hopefully improve the various pieces that go into a FHIR "Release".

1. R4 was "special" in that it had the first normative content. In the future, should we have R(n+1) only if there is new normative content, and in between we have balloted STU changes as R(n.m)?
2. We need to keep putting proposed changes to ballot. We cannot wait years. Is the current PSS process good enough for that, or do we need to improve it somehow?
3. Can we identify what is necessary to have R4A in April 2021, and R4B in December 2021, and R4C in April 2022, and R5 in December 2022?

Josh Mandel (Jun 04 2020 at 17:01):

I'm concerned about how decisions are made here. Who decides which features would "Get to belong" to a 4a release, and on what basis?

Lloyd McKenzie (Jun 04 2020 at 17:01):

We don't expect a final decision on whether to do R4A until the week after DevDays. If we were balloting in Sept, final content for the release would be due Aug. 9th. So about 6 weeks - over the summer, when most people are at reduced capacity due to work-at-home when children are out of school. The FMG didn't think that was reasonable for work groups to decide on what descriptive content should be moved/adjusted, do QA, etc. The next timeframe would have ballot closing in January. Even then, performing reconciliation and getting the publication out by April will be tight.

Lloyd McKenzie (Jun 04 2020 at 17:03):

The FMG's criteria for FMG have largely been based on content that we're confident won't have been implemented in the R4 release, so we can essentially treat the R4 versions as if they never existed. If we're going to look at touching stuff that might reasonably have been implemented, then there's no real choice except do an R5.

Lloyd McKenzie (Jun 04 2020 at 17:03):

(With all of the associated challenges of inter-version conversion between R4 and R5

Lloyd McKenzie (Jun 04 2020 at 17:05):

Decision would be made by FMG - the proposed criteria are on the Confluence page listed earlier. Feedback on those is welcome here.

Lloyd McKenzie (Jun 04 2020 at 17:13):

Performing a release typically includes 2 ballot cycles (one more short one if we're changing normative). We need to do QA on the release both before ballot and before publication. There are also tasks like writing up all of the changes, creating StructureMaps between the versions, etc. Another consideration is that we don't want to do a new release until implementers have had a chance to actually roll out support for the previous one - both so that our changes are informed by actual implementation experience and because there's no point in putting out a release without implementation. As well, we don't want to put out a whole bunch of releases in short succession. Each new release creates a need for mapping and a barrier to interoperability. In general, fewer releases with larger step changes works better for the community than more frequent releases. Even release 3 proved to be "too fast" for some of the community - and that was almost a 2 year gap.

Lloyd McKenzie (Jun 04 2020 at 17:15):

We've talked about the possibility that the pace of change might pick up once most things are normative - because then we don't have to worry about mapping/interoperability issues and the degree of the change tends to be less. But that's still several years away

Lloyd McKenzie (Jun 04 2020 at 17:17):

None of this is set in stone - we can try to adjust based on the needs of the community (both developers and implementers), but we need to consider the community as a collective, recognizing that different parts of the community have conflicting requirements. (The overall desire tends to be "change the pieces I need changed ASAP and don't change anything else for a long time"...)

Gino Canessa (Jun 04 2020 at 17:37):

Sorry in advance for the slightly longer post, but this is how I think, so you all get to come along for the ride (or skip, I can't actually make any of you read it :-)

To consolidate my understanding of the choices:

1. R4A - a more limited release about a year out (Q2 2021?). This pushes R5 to Q4 2022+.
2. R5 - roughly Q4 2021.

So, we're talking about six months earlier for a few resources, and a year later for the rest.

After a lot of thought (and some back and forth with Josh), I feel we need a larger discussion on release schedule/velocity/process. Right now, part of the issue is that releases are far apart (from looking at the directory: from DSTU1 to DSTU2 was roughly a year, DSTU2 to STU3 also about a year, but from STU3 to R4 was roughly two years, and from R4 to R5 we're looking at three years. This makes people want to push things through, because missing the window has a high penalty.

For certain, this stability is good for interop (fewer widely adopted versions), but resources earlier in development that need more churn suffer for it (as Lloyd is commenting while I'm writing this).

Unfortunately, I don't have any magic solution for this. DICOM runs with a fixed schedule of four releases per year, but they have a much larger base for normative / interop (e.g., generally speaking, a system from 10 years ago will still work with current systems - just not have access to some of the new stuff).

Once we get FHIR to a certain level of adoption/completeness, I think it will be crucial to adopt stricter standards for cross-version compatibility, but I don't think there's enough today for that to be reasonable.

To circle back to the immediate question - publishing six months earlier sounds great! But I don't think it will have any actual benefit. Systems running R4 would still need to be upgraded to R4A, and holding up all the other work would be detrimental to the standard and community as a whole.

TL;DR: As of right now, I would vote for just moving forward with R5 (though I'm still open to discussion).

Gino Canessa (Jun 04 2020 at 17:37):

@Rik Smithies, @Jose Costa Teixeira: Earlier in the thread you were asking about getting resources out for testing before releases...

• Connectathon builds: these are crucial since I believe now most languages get builds done for the milestones. Need to make sure everything is merged into the master branch when Grahame cuts the build.
• Extra work: for subscriptions, I ended up making a language generator for C# and TypeScript that works off a local build of the FHIR spec (on GitHub - but I've been working on a new project with better scope that will supersede it, Coming Soon(TM)). It's far more basic than the standard FHIR libraries, but lets you work with the models easiliy. With that tooling I made a reference implementation (here), with a proxy server that sits on top of a standard R4 server to add the functionality I want and a full client.

Vassil Peytchev (Jun 04 2020 at 17:46):

Does that mean that we may need releases for implementation (Rn.m) and releases for regulation (Rn+1)? And by release I mean something that has passed ballot. I would think having frequent implementation releases is better than infrequent "large step" releases as it will help to keep the focus of the community to a smaller set of ballot items. A set of requirements like the ones being considered for R4A can be used to limit the overall impact of more frequent releases. Inter-version mapping can in this case be only done between R(n) and R(n+1) releases.

Rik Smithies (Jun 04 2020 at 18:00):

@Gino Canessa

Systems running R4 do not need to be upgraded. In fact they can't be, because R4A is identical to R4 (for existing material), which is the whole point.

The benefit is that those who need the extras in R4A can start, and it harms no one (other than a delay to R5, which we are now seeking to mitigate).

I agree with Vassil, it is not good to expect people to make changes and wait 3 years for a release.

I know there is a long elapsed time in a release, with multiple ballots etc, and I know its complex, but waiting for all the cycles of one release to finish (which is 95% identical to R4) before starting work on the next release does not seem ideal.

Also we need to consider how much of it would formally be balloting anyway (a small amount I expect).

Nick George (Jun 04 2020 at 18:07):

Would there be "hidden" breaking changes to things like StructureDefinition, like there were from 4.0 -> 4.1? The most frustrating part of that transition was that it was billed as "basically a no-op", which might have been true for most users but required considerable work for implementors/tooling.

Rik Smithies (Jun 04 2020 at 18:13):

This is about mostly about new resources (and subscription, a workflow) so nothing that affects that level of infrastructure at all

Jose Costa Teixeira (Jun 04 2020 at 18:17):

Those that need the extras in R4 - can't that be achieved with the Connectathon builds?

Lloyd McKenzie (Jun 04 2020 at 18:17):

That's not entirely true. One of the candidates for R4A (keeping in mind that no final decisions have been made) is the stuff in http://build.fhir.org/types.html. That won't impact most implementations, but it will impact certain tool-builders.

Gino Canessa (Jun 04 2020 at 18:24):

@Rik Smithies , they still need to be upgraded - systems don't automatically get versions of FHIR. Developers will need to grab the packages, do some amount of work (e.g., adding new features, testing, etc.), and push out updates for those systems. Production systems will need to schedule an update and all that typically entails.

If you aren't clamoring for one of the features added, then you likely won't go through the effort. If you are clamoring, then what is the delta between that and R5?

Rik Smithies (Jun 04 2020 at 18:25):

@Jose Costa Teixeira if that were true we wouldn't need stable releases, just Connectathon builds. When building IGs for large projects, stakeholders want to see that it is based on something more solid.

Gino Canessa (Jun 04 2020 at 18:26):

Jose Costa Teixeira said:

Those that need the extras in R4 - can't that be achieved with the Connectathon builds?

For testing, yes. But for "real-world" implementation, not currently. I haven't come across a vendor that pushes out a new "release" for a connectathon build.

Rik Smithies (Jun 04 2020 at 18:27):

@Gino Canessa , I am missing your point I think. Why can't they just leave the code alone? R4 core would not change. Why recompile the same code?

Jean Duteau (Jun 04 2020 at 18:28):

so R4A is intended to be an official release (to enable those vendors that only support official releases) but with a reduced scope so that not everything is on the table.

Will we be branching the existing R4.0.1 to take in just the parts of 4.4.0 that we want?

Gino Canessa (Jun 04 2020 at 18:29):

I've never had a product I was willing to support [with] a library I hadn't built against (maybe this is different for others). In most of my experience, we even validated all binaries to ensure they are the version we validated against (for regulatory compliance, etc.).

Jose Costa Teixeira (Jun 04 2020 at 18:30):

if that were true we wouldn't need stable releases, just Connectathon builds. When building IGs for large projects, stakeholders want to see that it is based on something more solid.

So stakeholders want to see a solid formal publication, regardless of the solidity of the resources?

Rik Smithies (Jun 04 2020 at 18:34):

@Jose Costa Teixeira Yes. But those are two different things. We commonly release resources at all FMM levels, I don't think its proposed to stop releasing til things are at high FMM levels.

Lloyd McKenzie (Jun 04 2020 at 18:34):

There are no feature changes permitted for any resources except those edge ones + Subscription. So all the code associated with Allergy, Observation, MedicationRequest, Procedure, etc. SHALL run unchanged in R4 and R4A. If we can't do that, we wouldn't do an R4A.

Rik Smithies (Jun 04 2020 at 18:35):

@Jean Duteau Well its a full release, not a patch, but it just has a reduced scope of changes. I would expect a branch yes.

Jean Duteau (Jun 04 2020 at 18:35):

Lloyd McKenzie said:

There are no feature changes permitted for any resources except those edge ones + Subscription. So all the code associated with Allergy, Observation, MedicationRequest, Procedure, etc. SHALL run unchanged in R4 and R4A. If we can't do that, we wouldn't do an R4A.

Except that you just said that the underpinning stuff in types.html will be included so it's not "unchanged"?

Jose Costa Teixeira (Jun 04 2020 at 18:37):

I am fully supporting the need to get these resources out asap for trying out.
But is that the point? To have implementers try it and stimulate feedback?
Or do we want to have a milestone for stakeholders to feel this is stable (even if it may not be)? Some stakeholders don't handle agility that well after it's published.

Lloyd McKenzie (Jun 04 2020 at 18:37):

That will drive changes to authoring and validating tools, but shouldn't drive changes for EHRs, etc.

Jose Costa Teixeira (Jun 04 2020 at 18:38):

For example, would R4A include CodeableReference?

Jean Duteau (Jun 04 2020 at 18:39):

Jose Costa Teixeira said:

For example, would R4A include CodeableReference?

It would have to since the MedicinalProductDefinition class uses it.

Lloyd McKenzie (Jun 04 2020 at 18:39):

My understanding from Grahame is that CodeableReference wouldn't be allowed - MedicinalProductDefinition would have to be refactored for an R4A to not use it

Rik Smithies (Jun 04 2020 at 18:42):

which would be fine

Rob Hausam (Jun 04 2020 at 18:43):

So far, on balance, it's still sounding to me like we should get R5 done (and maybe try to accelerate that?).

Jean Duteau (Jun 04 2020 at 18:44):

Rob Hausam said:

So far, on balance, it's still sounding to me like we should get R5 done (and maybe try to accelerate that?).

I was just going to write that myself. I went and reviewed all of this thread and I just don't see why we don't start on an R5 now. It gets everything that this R4A wants along with other changes that implementations might also need.

Lloyd McKenzie (Jun 04 2020 at 18:46):

@Jose Costa Teixeira, I don't think it's appropriate for us to say "we don't trust you to respect our change rules, so we won't publish this thing as FMM1". Our change rules are clear. If implementers choose to lock down on the first release of a resource and yell and scream when we make breaking changes before normative, there's not much we can do about it.

Nick George (Jun 04 2020 at 18:50):

I'd be much less nervous about this if we didn't have the types changes.html. It seems to me that a 4 -> 4a that uses all the same core defining rules, but just tweaks some structure definitions is pretty reasonable. Changes to underlying schema I'd prefer to see in a major release

Nick George (Jun 04 2020 at 18:52):

especially since we already messed with types in 4.1...

Vassil Peytchev (Jun 04 2020 at 19:01):

I am concerned that if we don't make the effort now on designing a good release system, we will end up with FHIRv2 before we can get R5 out.

Jose Costa Teixeira (Jun 04 2020 at 19:01):

@Lloyd McKenzie I don't think I wrote we should prevent publishing because we don't trust them to respect the rules, or at least it was not meant as such. We should not prevent publishing as FMM1 - I'd want these out asap to be played with, and I asked if it is possible to move forward without an official release. And I'm good with yelling and screaming (I do my share).

Jose Costa Teixeira (Jun 04 2020 at 19:08):

@Vassil Peytchev yes, improving our release system ("designing" sounds starting over), seems an important priority that we should take on.

Rik Smithies (Jun 04 2020 at 19:17):

@Jose Costa Teixeira stakeholders want official releases, it is clear. Ideally they want normative, but they know they cannot have that, because of the way FHIR works, and that is acceptable. But they don't want rolling builds. If that was ok we would never need FHIR releases. They know FHIR works on official releases, so they want official releases.

Patrik Sundberg (Jun 04 2020 at 19:19):

In practice, isn't this just saying R5 will be scoped down (and called R4A)? If so, why not do it that way, call this proposed release R5 instead of R4A, and move the majority of R5 into R6, to be released late 2022?

Rik Smithies (Jun 04 2020 at 19:20):

@Jean Duteau @Rob Hausam I think the problem is that we did already start on R5 and it is taking years and getting further way. When asked, most said they did not need R5 yet (I think "most" did not include those hacking on the standard), so in fact R5 is not urgent, for many. But for a key group it is. R4A is a way to keep both groups happy (but I really don't want to see R5 pushed back so far).

Jose Costa Teixeira (Jun 04 2020 at 19:22):

Rik Smithies said:

Jose Costa Teixeira stakeholders want official releases, it is clear. Ideally they want normative, but they know they cannot have that, because of the way FHIR works, and that is acceptable. But they don't want rolling builds. If that was ok we would never need FHIR releases. They know FHIR works on official releases, so they want official releases.

True. Every stakeholder wants official and stable. I use my IGs to give them that stability - with more or less extensions, but they have a working solution. And they can have normative, sure. We'll get there. After iterating and eventually changing.
My stakeholders want a stable working solution, they don't ask "when is this normative in FHIR". (That is what triggered my spider sense fwiw).

Jose Costa Teixeira (Jun 04 2020 at 19:24):

Patrik Sundberg said:

In practice, isn't this just saying R5 will be scoped down (and called R4A)? If so, why not do it that way, call this proposed release R5 instead of R4A, and move the majority of R5 into R6, to be released late 2022?

Yes, that (and I think a bit of scoping decision that comes with it).

Gino Canessa (Jun 04 2020 at 19:25):

That still pushes a lot of "in progress" work out 2.5 years for R6.

Rob Hausam (Jun 04 2020 at 19:29):

I certainly understand the desire and the point that you are making, @Rik Smithies. But I think the work that we've done so far on ConceptMap updates and CodeableReference (and probably some other things) also needs to be included - and that makes it necessarily R5. So I think that overall the best bet is to see how we can work to get to R5 sooner (if possible), rather than later.

Jens Villadsen (Jun 04 2020 at 19:41):

Depending on the definition of stakeholder, I've never meet a client (as in stakeholder) that really cared about normative. Clients cares about getting their solution done and how the solution supports their business requirements.

Jean Duteau (Jun 04 2020 at 19:43):

Jens Villadsen said:

Depending on the definition of stakeholder, I've never meet a client (as in stakeholder) that really cared about normative. Clients cares about getting their solution done and how the solution supports their business requirements.

Ah, unfortunately, you haven't worked with enough local governments then. :( In Canada, we had such a hard time getting provincial health agencies to implement things until they were normative - even when we explained that a step in getting the spec to go normative was having them implement them and provide their feedback! I think that the FHIR community has done a great job in making that message front and centre, but I'm still getting some pushback from government agencies who want that "stamp" before they'll expend resources.

Jens Villadsen (Jun 04 2020 at 19:45):

@Jean Duteau I work all the time with the danish government agencies and regional authorities. They care for getting their problems fixed, not whether stuff is normative or not

Jean Duteau (Jun 04 2020 at 19:46):

Jens Villadsen said:

Jean Duteau I work all the time with the danish government agencies and regional authorities. They care for getting their problems fixed, not whether stuff is normative or not

Good on the Danes then! Could you export some of that understanding over to this side of the pond? :)

Jens Villadsen (Jun 04 2020 at 19:47):

@Jean Duteau Have your agencies ever experienced that making a FHIR resource normative fixed some problem in the real clinical world?

Jean Duteau (Jun 04 2020 at 19:48):

Jens Villadsen said:

Jean Duteau Have your agencies ever experienced that making a FHIR resource normative fixed some problem in the real clinical world?

You're talking to the converted. It is not about an actual benefit of normative but rather the perceived "we can't afford to implement something that isn't stuck in stone".

Jean Duteau (Jun 04 2020 at 19:51):

And at least now with how FHIR works and the message that the community has conveyed, it is no longer "we need to wait until this is normative" but rather "we need to wait until this is in an official release". Baby steps, baby steps...

Jens Villadsen (Jun 04 2020 at 19:51):

reverse that argument: "how much should it be carved in stone"? why wait for normative when you can wait for it indefinitely :) the best case would be if you waited so long that your problem would be way worse once you got normative status

Rik Smithies (Jun 04 2020 at 19:59):

@Patrik Sundberg yes same content, but for appearances, having an R5 that is very small and doesn't do much of what was promised for that release doesn't look good. It shouldn't matter but it does :-)

Jens Villadsen (Jun 04 2020 at 20:01):

@Rik Smithies what has been promised as part of R5?

Rik Smithies (Jun 04 2020 at 20:08):

Maybe promised isn't the right word but there's been continuous talks about what is coming, at high level and in any number of committees, workgroups etc and the companies those folks work for. People will be expecting what is being worked on by us all.

Grahame Grieve (Jun 04 2020 at 20:33):

Well, catching up on this thread now that I'm awake:

• we can talk about improving the release process, and we have to, for an R4A to exist, but I'm not sure what particular improvements will make any difference here. The principle issue we have is resource limitations. There's no magic wand to wave that reduces the time it takes. Publishing and Balloting takes a lot of time
• an R4A will take me a couple of months to set up (estimate). As yet, I have not begun to address the question of who's going to fund that work which is outside my plan
• @Nick George you're talking about 4.0.1 not 4.1, and that's pretty important in this thread. Yes, we did make some 'fixes' to the underlying structure definitions that caused work for tooling vendors and the type changes do create work too. Those changes might not be possible, and if they're not, my own work increases (2-3 weeks more?)
• @Rik Smithies it's not as simple as 'don't need to do anything for R4A' - the question is what version you claim to support in your CapabilityStatement and your various IGs. We cannot rewrite history and make 4.0.x refer to different structures. It has to be something different, and merely changing the version claim will create a series of ramifications
• @Jean Duteau You can make the case the AdverseEvent is a candidate for R4 but it sounds unlikely to meet the criteria to me
• @Rob Hausam yep, ConceptMap changes would not be possible under this scenario. The most the committee could do is change the display names of the existing codes for clarity, though I think that FMG would reject that change too. But the committee should navel gaze on it's plans if a year more on a 2year plan flips from 'this is a good idea' to 'this is impossible'

overall, I'm glad to see that we flushed out a desire for R5. Market feedback to this point has been strong: don't get to R5 any time soon.

There's a different possibility: to STU 4.6 as 4A, knowing that (a) it will contain changes to normative resources that are not normative so (b) no one will actually implement it, except if they are locked off from that, which means the regulatory medicine resources. E.g. a useless point release to resolve their misplaced concerns about process (the concerns are real, but us stamping them with some approval process that isn't organic and coming from them doesn't really make any difference. I'd love to see evidence that I'm wrong)

Rik Smithies (Jun 04 2020 at 20:41):

is there any scope for saying that new content in R4A would not be balloted (except for comment)? It goes against the grain to not have a ballot but there is merit in publishing without ballot, lots of resources versions have been.

Vassil Peytchev (Jun 04 2020 at 21:10):

is there any scope for saying that new content in R4A would not be balloted (except for comment)? It goes against the grain to not have a ballot but there is merit in publishing without ballot, lots of resources versions have been.

I don't think this is a good idea - releases need to reflect balloted change, IMO.

we can talk about improving the release process, and we have to, for an R4A to exist, but I'm not sure what particular improvements will make any difference here. The principle issue we have is resource limitations. There's no magic wand to wave that reduces the time it takes. Publishing and Balloting takes a lot of time

I think there are two issues issues to be resolved as part of publishing 4A:

• What do releases mean (besides that there is new balloted content)
  • Does R5 mean that there is new Normative content?
  • there are obvious pockets of activity within the community, how can more frequent point releases (non-normative) help while maintaining quality?
• How to alleviate the resource limitations?
  • Does something like the Linux kernel release process provide useful guidance (e. g. develop changes as branches from last release, first ballot is done on that branch , then merge in main "next release" branch for second ballot).

Rik Smithies (Jun 04 2020 at 21:15):

re the CapabilityStatement, I assume R4A would have a new version - I don’t want to rewrite history (any update has a new version). But wouldn’t that only affect servers that actually go to R4A (a minority) and yet also want to support version aware clients still on R4, without updating them - an even smaller group, especially given the relatively standalone nature of the proposed changes, which cannot be implemented on R4 anyway.

Gino Canessa (Jun 04 2020 at 21:52):

In the current scope doc, the proposal says:

• Tooling will only support a single 4.x release (i.e. once 4A is out, validation against 4.0.x will no longer be possible/necessary)

I read that as R4A will work the same as technical corrections - e.g., the old version is removed. Could someone clarify?

Peter Jordan (Jun 04 2020 at 21:57):

The showstopper for me is this statement in the Proposed Guidance...

"Tooling will only support a single 4.x release (i.e. once 4A is out, validation against 4.0.x will no longer be possible/necessary)"

I don't see any way that HL7 can enforce 4.0.1 implementations to migrate to R4A (consider how long it's taken for many to move from draft/trial use versions) and cutting them adrift from tooling such as the Validator and IG Publisher would be damaging to the Community as a whole.

As Grahame has remarked, the responses to this proposal - thus far - have flushed out a significant demand for R5. Let's get on with that!

Josh Mandel (Jun 04 2020 at 22:32):

stamping [Medication Definition resources] with some approval process that isn't organic and coming from them doesn't really make any difference.

Agreed @Grahame Grieve -- but focusing an entire release on these resources and delaying everyone's hard work on R5 content by at least half a year seems even worse. Why should one stakeholder group have so much sway?

So, reflecting on discussion above: I think our time would be better spent investing in ways to increase release velocity overall, not cranking out a narrow and distracting 4a release (or a pointless point release).

David Pyke (Jun 04 2020 at 23:38):

Josh Mandel said:

So, reflecting on discussion above: I think our time would be better spent investing in ways to increase release velocity overall, not cranking out a narrow and distracting 4a release (or a pointless point release).

I wholeheartedly agree. Pushing out R4A (or whatever the versioning will call for) would be a distraction to the work for R5. I understand some groups would like their refactors/fixes pushed out sooner but I can't see a benefit to FHIR or the market as a whole.

Lloyd McKenzie (Jun 05 2020 at 00:29):

@Peter Jordan The intention would be that the validator would interpret 4.0.1 as 4A.0.1 (or whatever the heck we do with semantic versioning) such that the tools would only support one version, but implementers declaring 4.0.1 would still work as they always had. The intention is to, as much as possible, make the introduction of 4A a non-event for those already implementing R4 with the exception of those working on the resources that are specifically scoped to change. (The inclusion of the Subscription change would be dependent on any R4 implementers of that resource being willing to migrate that work immediately - we wouldn't easily be able to support/tolerate the original R4 implementations.)

@Rik Smithies We can't move any content from Draft to STU without going through ballot and reconciliation - end stop.

@Grahame Grieve If we were to put out an R4.6 that included substantive changes to STU content, we couldn't exclude those changes from ballot. That means we'd need to do proper QA on all that content - and work groups would definitely want to ensure their ducks were in as much of a row as possible. We could possibly skip the notion of making anything normative, but I don't see how we'd change the schedule for release of an R4.6 instead of an R5 by more than 4 months or so. I guess we could do that if we wanted to declare up front that we consider it to be a stillborn release that would only be adopted in closed communities that are urgently dependent on it. Personally, I'd prefer a stillborn R5 to a 4.6 because at least then we'd have pushed more stuff to normative, which would give implementers some confidence in planning their way forward.

Patrik Sundberg (Jun 05 2020 at 00:37):

Overall this conversation sounds like the generic tradeoff discussion you get when you have periodic releases of a product. Everyone wants to get their feature out (for legitimate reasons) and it becomes difficult to set release dates. Long periods between releases make this problem more acute; it especially increases the cost of missing a release, which then makes people push even harder for getting their feature into the release. So, +1 on the comments by @Josh Mandel and others on increasing release velocity. One aspect of that is the ability to downscope, pushing features to the next release. It sounds to me like there is actually quite a lot of interest in getting an R5 release out, but it should include all the work that is close to completion now, and can be balloted "quickly", not just the changes that were the original motivation for this discussion. And some of the work that's further out will be in R6. Maybe that's not so bad?

Grahame Grieve (Jun 05 2020 at 00:52):

The problem is that market generally is pushing back against more releases. @Patrik Sundberg you've spoken to me along those lines directly

Grahame Grieve (Jun 05 2020 at 00:54):

with regard to the tooling - the intent would be that the reference implementations and test servers would update to R4A rather than maintaining both R4 and R4A, and the internal tooling to the validator (for instance) would use R4A instead of R4). This would not force any change to implementers unless they are using the resources that change as part of R4A

Grahame Grieve (Jun 05 2020 at 00:57):

Generally, R5 is slipping because:

1. The market has been asking us to do that
2. we're putting such a huge amount of work into R4 implementation
3. Out ability to get work done is much compromised by travel restrictions and there's no reason to think that'll change soon

And when we surveyed everyone, they shrugged and said there was no hurry. Except for 2 specific groups of stake holders; hence this discussion. Although people have pointed out that as we get more mature content, and still acquire new content in specific domains, the problems of a multi-speed community will increase

Grahame Grieve (Jun 05 2020 at 00:59):

I'm also suspicious of the idea that it's so easy to delay things from R5 to R6. There's both editorial issues with that, and also committee process issues. No one suggesting that it should be done is responsible for figuring out what it means to actually do it

Grahame Grieve (Jun 05 2020 at 00:59):

it's generally easy to see how to defer modules but most of the changes we deal with are not modular

Lloyd McKenzie (Jun 05 2020 at 02:53):

Increasing tempo is also challenging because when we do a new release, the whole spec goes out to ballot. As the spec grows, that takes more and more effort. And during ballot, the number of reviewers increases as the amount of interest/dependence on FHIR increases. However, the pool of people who work through the resolution process tends not to scale as much. We may be able to tweak the processes used by those people to scale a bit better, but we need to ensure that we don't bypass the thoughtful consideration that's part of the review process. As we get to the point where more and more content is normative, we can sort of 'skip' a large portion of that content.

Rik Smithies (Jun 05 2020 at 11:16):

I think we have shown enthusiasm for R5 from us here who build FHIR - which is natural. Whether that is shared by the broader community, I am not so sure. Has that picture actually changed?

If there was an R4A I would expect it would better if it was not a replacement of R4. For implementers, why wouldn't it just be plug compatible (other than a version number change to implement), so people can easily take advantage of the new parts, not breaking the old, but not have it forced on them.

If this is meant to minimise impact on tooling it seems to have the opposite effect (everyone would need to work with it, rather than just choosing to). Naturally it helps if tooling doesn't ignore this release. Tooling will need to go to R5 eventually of course, including the R4A content.

David Pyke (Jun 05 2020 at 11:51):

I think one thing that's missing is that in the US, ONC has mandated R4 V4.0.1 and there are huge efforts underway to get that started and running by the deadlines. If we start muddying the water with a new release, especially when the market is pushing back on an R5 release, we risk alienating the market. We finally have the mandate to get FHIR into the market as a whole and we're looking to break compatibility with what's mandated for a few organizations who have requirements that R4 doesn't meet.

I think we should seriously consider sticking to the relaxed timeline for R5 and not send a new breaking change into the market while it's still learning about R4. Let's get the FHIR installed base in place and then we can start releasing the improvements. Major releases just to fix a few aspects seems like a very self-centred view.

John Moehrke (Jun 05 2020 at 13:17):

I seem to recall that HL7 STU rules allow updating a STU without balloting. Seems US-Core does this... so why can't some of this sub-normative work be done that way? How is that different than the releases we make for dev-days and connectathon?

John Moehrke (Jun 05 2020 at 13:19):

Why can't subscription and medication needs be satisfied by IG publications?

Vassil Peytchev (Jun 05 2020 at 13:20):

They have new resources that don't exist in R4.

John Moehrke (Jun 05 2020 at 13:22):

Vassil Peytchev said:

They have new resources that don't exist in R4.

make the resources in the IG

David Pyke (Jun 05 2020 at 13:34):

That makes Basic into a monster. YOu should look through the backporting guide.

Vassil Peytchev (Jun 05 2020 at 13:51):

Increasing tempo is also challenging because when we do a new release, the whole spec goes out to ballot.

I suspect you mean "the ballot contains the full spec as a whole", but it is possible to ballot only specific parts, correct?

Brendan Keeler (Jun 05 2020 at 14:06):

tenor.gif

Lloyd McKenzie (Jun 05 2020 at 14:25):

@Vassil Peytchev It is possible to ballot only specific parts - but that means the publication can only contain changes to those parts. Given that we get thousands of change requests each year and we update the CI build as we go, it's a significant process burden to create a snapshot in which certain things change and others do not. (And as usual, everyone wants their change in and everything else to stay the same.)

@Rik Smithies If R4A wasn't going to be plug and play substitutable for R4, then it wouldn't be R4A - it'd be R5. The whole notion with R4A was to make it transparent to those implementing R4, but allow certain resources around the boundary to advance to STU. The changes to everything else would have to wait until R5 - which would happen closer to the time when the implementer community was actually ready to consume i.

Rik Smithies (Jun 05 2020 at 14:46):

I agree it should be transparent and substitutable, but also something that those who didn't need the features can safely ignore. That seemed a worry for people.
I also think stakeholders may be less bothered about STU than FMM + being in a published version (with other newly STU things, but not necessarily (all of) theirs, yet).

Josh Mandel (Jun 05 2020 at 15:17):

Why can't subscription and medication needs be satisfied by IG publications?

For subscriptions, we think we have a "good enough" solution to making R5-like (i.e., Topic-based) subscriptions work against R4; Gino is working on a "back-port" IG to describe this, so I definitely wouldn't take "we need subscriptions" as an argument for a 4A release.

Gino Canessa (Jun 05 2020 at 15:32):

David Pyke said:

That makes Basic into a monster. YOu should look through the backporting guide.

@David Pyke, if you're talking about Subscriptions (backport) we're working on a different version. WIP is here. So far I've been more focused on the models/examples than documentation, so most of the useful content can be found in the Artifact Index.

David Pyke (Jun 05 2020 at 15:44):

Okay, then we should remove the Subscriptions update from the list of reasons on the R4A doc that Lloyd pointed to. So, then Medications would be the current main justification?

John Moehrke (Jun 05 2020 at 16:11):

Lloyd McKenzie said:

Vassil Peytchev It is possible to ballot only specific parts - but that means the publication can only contain changes to those parts. Given that we get thousands of change requests each year and we update the CI build as we go, it's a significant process burden to create a snapshot in which certain things change and others do not. (And as usual, everyone wants their change in and everything else to stay the same.)

Rik Smithies If R4A wasn't going to be plug and play substitutable for R4, then it wouldn't be R4A - it'd be R5. The whole notion with R4A was to make it transparent to those implementing R4, but allow certain resources around the boundary to advance to STU. The changes to everything else would have to wait until R5 - which would happen closer to the time when the implementer community was actually ready to consume i.

we will eventually get too big to ballot as a whole.. is this our moment?

Vassil Peytchev (Jun 05 2020 at 16:22):

John Moehrke said:

we will eventually get too big to ballot as a whole.. is this our moment?

I think it is. I will try to get a rough proposal going on that...

Lloyd McKenzie (Jun 05 2020 at 16:44):

It's not a question of "balloting" as a whole, it's a question of "publishing" as a whole. FHIR core is deeply intertwined. There's no feasible way to publish some parts of it independent of other parts. The whole thing needs to go together. And so long as we're making changes to the whole thing, we need to expose everything that's changed to ballot review. We could, eventually, institute rules prohibiting changes of any sort other than technical corrections to certain parts of the spec without explicit permission, but I can't see that flying well. Even with v2, we reballot the whole spec each time. However, given that so much of it is stable, the amount of effort declines. We haven't hit peak 'effort' for FHIR yet. And I expect we won't until around R6 or so.

John Moehrke (Jun 05 2020 at 17:37):

just because that is the way we did v2 and v3 and cda... does not mean it must be our future. I very much expect the transition will be painful.

John Moehrke (Jun 05 2020 at 17:38):

along these lines... why can't the CI build be used by the medicine need? Other domains have used the CI build until a formal release. Yes it means you need to push tools suppliers to do something extra, but it is purpose specific push and that push can usually be funded by those that need it rather than everyone else.

Vassil Peytchev (Jun 05 2020 at 17:42):

To make sure I am not off-base here, ideally, we want to have:

1. A CI build "stream" (for lack of better word), as the master branch is now
2. A publish "stream", where the changes going into next ballot, and from where subsequent releases are branched, so that the ballot publication contains the whole specification, but only with the changes under ballot.
3. Keep the two streams in sync.

It seams to me that a with the inherent capabilities of Git (e.g. git rebase) and relatively uncomplicated process changes this should be achievable. I will try to flesh it out so it can become the basis of discussion.

This is independent from the decision of what goes into ballots and releases, which will need to be decided as well - e.g. is it a good idea the distinguish between R4.x having full backwards compatibility to R4, while R5 allows breaking changes; whether an R4A release can become a substitute of 4.0.1; etc...

Rik Smithies (Jun 05 2020 at 17:47):

@John Moehrke
Because governmental departments and EU multi-national agencies don't feel comfortable implementing based solely on a rolling CI build. They want something they can call a "Standard", and while what that is is a little fluid these days, it isn't a CI build timestamp.

John Moehrke (Jun 05 2020 at 17:54):

Rik Smithies said:

John Moehrke
Because governmental departments and EU multi-national agencies don't feel comfortable implementing based solely on a rolling CI build. They want something they can call a "Standard", and while what that is is a little fluid these days, it isn't a CI build timestamp.

My point is that many had to use CI build in pre-DSTU2 and pre-STU3 and pre-R4 days... There is precedent; There are CI branches created for purpose-specific needs, like connectathon or devDays.. These new actors are just new, not special. sometimes one needs to recognize that their own urgency is not everyones urgency. I get the desire, I don't fault them for asking. I am just noticing the impending pain to the whole community for the needs of a few (relatively speaking).

Vassil Peytchev (Jun 05 2020 at 17:58):

On the other hand having government regulations based on non-balloted snapshots defeats the purpose of interoperability.

Lloyd McKenzie (Jun 05 2020 at 17:59):

Git rebase with XML Excel files doesn't sound like a lot of fun for me. If we managed to ditch spreadsheets (moving resource authoring into ???), we'd still need to be much more robust about how commits were done so that it would be feasible to have tight control about exactly what was (and was not) moved into the 'ballot/publish' branch. Many (most?) committers currently just push 'here's a bunch of new stuff' across whatever resources and pages they happened to be working on. Changing that is going to create more burden on both committers and those who oversee the commit process.

Even if we did that, the reality is that the implementer space doesn't want frequent releases. Every release means mappings, complexity and impedance mismatches with other systems. It seems to take 2-3 years for a release to go from "published" to "well-implemented". Cycling faster than that just means releases get skipped (and the risk that different releases get skipped by different systems).

Rik Smithies (Jun 05 2020 at 18:04):

@John Moehrke well yes, early adopters do that. We want to bring national and international regulatory agents to the table (and the whole industries that they control), and they are not early adopters.

It would be good to make things comfortable for them, but I don't want it to have large downsides for everyone else.

But getting a release once every 3 years minimum - which is what we are talking about for changes made just after R4, with R5 earliest at the end of 2021, does not seem good to me. I know everyone's changes will be 3 years old but this is particularly key for regulatory, because of the way the timing fell.

There is more or less nothing they can use in R4 (since we were just getting underway near the end of STU3 and there were some unusually big hurdles getting this into FHIR), and there is a good deal now. So there is a particular benefit to be had and it seems (relatively) low hanging fruit. (Yes, special pleading :-) )

Patrik Sundberg (Jun 05 2020 at 19:56):

Grahame Grieve said:

The problem is that market generally is pushing back against more releases. Patrik Sundberg you've spoken to me along those lines directly

Yes, I personally don't feel a strong need for a new release currently. In some ways, it would be nice to have another year or two without having to worry about R5. The STU3 -> R4 upgrade was somewhat painful for us, but we've been putting a lot of things in place that will make R4->R5 smoother, when that transition comes. I suspect others have gone through a similar process.

I also suspect that one day, I will be among the set of people waiting for some critical new feature, and thinking of ways to speed that process up. Hence my concerns about release velocity. If there's a well understood expected cadence, people will eventually adapt to that. We're expecting an end-of-2021 R5, for example. Pushing that out further because of R4A doesn't quite sound right. Releasing an earlier, smaller scoped R5 would be a better option imo, but I don't quite know the details enough to say whether that's actually a feasible option (sounds like it may not be). If it's not, my personal opinion is that the current plan, with no R4A and an R5 release end-of-2021 is the best option.

Peter Jordan (Jun 06 2020 at 01:17):

@Rik Smithies if all the current versions of the Medication Definition resources were placed in R4A release, they'd still be at FMM Level 0 or 1. Surely that wouldn't be sufficient for usage by national and international regulatory agents?

Lloyd McKenzie (Jun 06 2020 at 01:27):

The would be level 1 - i.e. STU status rather than 'draft'. My understanding from the regulators is that there won't be any implementation until the specification is referenced by regulation, so FMM1 is about as far as we can go. (Obviously there are challenges in that whatever is regulated is likely to change before it progresses to normative.)

Rik Smithies (Jun 06 2020 at 12:39):

The key ones are FMM1 in the build now and have been for a while. But in R4 they are level 0 and have different names, so in effect they don't exist. Most tools and servers won't work with them at all, so it's hard for implementers or IG builders to get started. We want to get above level 1 and are working on that, and planned to be higher by the original R5 date via connectathons. Software can be made based on CI builds, it's just formal IGs and large programmes that need something more concrete. Basing an IG on FMM 1 or 2, given that by the time the IG is actually in early implementation things could be at 2 or 3 seems reasonable.

Richard Townley-O'Neill (Jun 08 2020 at 06:29):

If R4A is branched from 4.0.1 with only additions and no changes, apart from references in the directory pages (such as http://hl7.org/fhir/R4/resourcelist.html) will that meet the needs of the meds community and be clearly enough defined to be reviewed in a small amount of time? It would mean that both MedicinalProduct and MedicinalProductDefinition are defined, but at least MPD would be available with the new name.

Rik Smithies (Jun 08 2020 at 13:18):

I would expect that it wouldn't be literally "additions" but updates in a narrowly scoped area. So I would expect removal of MedicinalProduct and addition of MedicinalProductDefinition (equivalent to an update, which is how it got the way it is now).

Lloyd McKenzie (Jun 08 2020 at 14:27):

R4A is based on the premise that the only people who care about the MedicinalProduct stuff will all migrate to the new version and have no interest in the stuff that was in 4.0.1 - because all tooling would cease supporting the 4.0.1 release. If that's not a valid assumption, then the 4A notion isn't going to be viable.

Rik Smithies (Jun 08 2020 at 15:00):

That is the premise, yes. The issue was only that if taken literally as "additions" then that wouldn't allow removing the unneeded old things, which we have now evolved away from (well, renamed). We can be more flexible than that and still fulfil the premise.

Grahame Grieve (Jun 10 2020 at 12:17):

ok so I after listening to the debate, I have a revised proposal for us to discuss.

• we continue working on R5 as we are now
• the first ballot is an STU we label R4B. We are specifically balloting a limited subset of the spec, but we are also publishing other changes too, as the first preview ballot of R5 (what would otherwise be draft ballot)
• we publish the reconciled version of the as R4B which is also the first normative ballot source for R5

This doesn't slow R5 down, doesn't fork the source, and does mean that we have an STU of some content more quickly than we get R5

Lloyd McKenzie (Jun 10 2020 at 14:38):

"This doesn't slow R5 down" - actually it does a bit. Normally our first ballot is a 'for comment' ballot, which means:
a) reconciliation is not required for all submitted items
b) we don't have a publication process after that (the publication process involves a significant amount of QA and polish before we put out the release)

Also, it means that R4B will not be wire compatible with R4 - and will also likely not be wire compatible with R5. Given that R5 will be following shortly on its heels, it will likely end up being an orphan release with minimal adoption and little/no tooling support. Is that what we actually want.

Lloyd McKenzie (Jun 10 2020 at 14:43):

As well, this would mean less time prepping for the STU (work group ducks need to be completely in line for December 2020 rather than April 2021)

When dealing with reconciliation for the STU, we typically ballot normative in parallel, then have a second normative ballot and have the 'final' QA and reconciliation for everything done at the same time. It's unlikely that we'd have reconciliation for the STU ballot in Jan. cycle ready to publish before the first version of normative went out in May. At best, this seems like we'd get the STU release out sometime summer 2021 and the normative release out by end of 2021. Is there really much benefit in that?

Grahame Grieve (Jun 10 2020 at 20:15):

yes it does mean all that. I agree. Though I'm not worried about the reduction in time, since this involves a whole lot less work. It does mean more work on the ballot. But that relates to the choice of scope

Grahame Grieve (Jun 10 2020 at 20:16):

I'm also looking forward at this as an ongoing pattern - faster iteration of selected immature sub-domains while the core rolls over slowly. It became clear, based on the comments in this thread, that the initial R4A proposal was not a viable path for this time, let along a suitable pattern for going forward

Lloyd McKenzie (Jun 10 2020 at 21:15):

Faster iteration that doesn't have tooling support and isn't widely implemented doesn't necessarily provide what the community who needs stuff to move faster wants...

David Pyke (Jun 30 2020 at 18:55):

Just thought I'd follow-up on this a bit. I'm working in the same direction as id-only for the Carequality subscription IG. How are you setting up the CapabilityStatement for id-only?

Grahame Grieve (Jul 01 2020 at 01:53):

I don't understand this question

Yunwei Wang (Jul 14 2020 at 16:09):

Is the official name changed from "R4A" to "R4B"?
What is the impact on validation? I assume HL7 R4 validator will support both 4.0.1 and R4A/B. Is that correct?
If this is an "orphan release" as noted, what is the purpose of this release? There will be no desire to implement this version knowing it would be thrown out in a few month.
What is the impact on US Core? @Eric Haas

Vassil Peytchev (Jul 14 2020 at 16:15):

I believe at the FHIR-I call yesterday it was made clear that the next release will be R5, and there will be no interim release.

Yunwei Wang (Jul 14 2020 at 16:44):

Really? I cannot recall that. @Josh Mandel

Josh Mandel (Jul 14 2020 at 20:09):

This came up toward the end of the call, in response to a question from Eric about planning for associated IGs; I indicated that it looks like the next release will be R5.

Yunwei Wang (Jul 15 2020 at 13:38):

Is R4B still on the table? @Grahame Grieve

Grahame Grieve (Jul 15 2020 at 13:52):

FMG still discussing options

---

Last updated: Apr 12 2022 at 19:14 UTC