FHIR Chat · R5 Roadmap Discussion · R4A/B/R5 Discussion

Stream: R4A/B/R5 Discussion

Topic: R5 Roadmap Discussion

---

Grahame Grieve (Feb 28 2022 at 11:33):

Placeholder for discussion about https://onfhir.hl7.org/2022/02/28/soliciting-feedback-concerning-the-roadmap-for-fhir-r5/

Simone Heckmann (Feb 28 2022 at 16:33):

Some perspective from Germany: We're currently both "well into the implementation phase based on R4" and very keen for specific changes in R5". Realistically however, most of the implementation projects will not allow an R5 migration within the next 2 years, hence most will probably skip it entirely and move straight to R6(+). Our current apporach is mainly to "preadopt" any additions made in R5 we find useful as R4 extensions.
So we're eager to see it released, but only as a stable bucket of international extensions, rather than a normative spec.
Option #3 it is.

Elliot Silver (Feb 28 2022 at 16:35):

Can you expand on "it’s the normative parts of the specification that present the most procedural work and risk with the R5 ballot"? Is there an estimate of the work needed to polish off R5?

Will creating an R4C (which, in terms of effort and HL7 process, won't likely be able to go to ballot until September or even January) be more effort than holding off R5 for a ballot cycle or two to finish off the outstanding work?

Elliot Silver (Feb 28 2022 at 16:38):

@Simone Heckmann I don't really understand the "we'll wait for R6" philosophy. I can understand "we don't want to change too often, so we'll standardize on one version for 5 years, and ignore releases in the mean time", but if R5 is two or four or ten years out, are you still going to wait for R6?

Simone Heckmann (Feb 28 2022 at 16:40):

Please read „R6(+)“ as shorthand for „whichever Version is current or just around the corner at the time when projects will begin to consider moving to a newer version of FHIR“

Lloyd McKenzie (Feb 28 2022 at 17:00):

Keep in mind, that timelines around R6 are totally up in the air - so whether that's 1.5 years after R5 or 4 years after R5, we don't yet know...

Vassil Peytchev (Feb 28 2022 at 17:23):

Can you expand on "it’s the normative parts of the specification that present the most procedural work and risk with the R5 ballot"? Is there an estimate of the work needed to polish off R5?

What I understand from this is that "promoting" most (all?) of the intended resources to normative needs a lot of careful work. If my understanding is correct, I think that balloting and publishing R5 with only few "promotions" will serve implementers best.

Lloyd McKenzie (Feb 28 2022 at 17:34):

My biggest concern is that, whether we 'promote' resources to normative or not, by the time we get to "R6", those resources will be treated as de facto normative - i.e. the community will not tolerate breaking change. (We might argue that some of them are in that state already). Doing the work to move the resources to normative essentially means doing alignment, clean-up and polishing that will allow us to be comfortable with them being locked down. If we defer, then we risk them being locked down in a messy state.

John Moehrke (Feb 28 2022 at 18:36):

those that don't follow the advice given on FMM numbers are at their own risk.

Lloyd McKenzie (Feb 28 2022 at 19:43):

No, they're not. Because if the community says "don't break this, it's too widely used", then the fact we've asserted FMM2 doesn't matter.

Peter Jordan (Feb 28 2022 at 21:05):

I completely agree with Lloyd's last comment and it illustrates why we are 'between a rock and a hard place' here. One thing that is clear to me is that maintaining two publication streams (R4x and Rx) isn't feasible (or even desirable) beyond R4B. The big question is whether the section of the community pressing for R5, including breaking changes to widely-used resources, is comfortable with where that will place them, from an interoperability standpoint, within their eco-systems. This, and the fact that we don't seem to be ready to make all the clinical resources normative, leads me to believe that Grahame's Option #3 is the best solution.

John Moehrke (Feb 28 2022 at 21:16):

so then why do we waste our time with FMM, or standards lifecycle at all?

John Moehrke (Feb 28 2022 at 21:18):

My understanding of the FMM and Trial-Use are signals to the using community, a signal that they should see as a warning and see as an invite to approach HL7 to actively engage and help mature the specification. Those that don't engage, should not be given priority over those of us that do engage.

Peter Jordan (Feb 28 2022 at 21:23):

... well the logical conclusion of that argument would be to only include normative resources in IGs.

Gino Canessa (Feb 28 2022 at 21:41):

I feel like we have had a flavor of this discussion several times... There are groups that want stability and fewer releases and there are groups that want more rapid iteration.

Generally, the people touching 'normative stuff' are in the former, people adding new content are the latter, and most people fall in-between depending on what they are working on at the moment.

I have a todo on my list to write up a retrospective on topic-based subscriptions - which are currently not substantially different from the versions we ended with in 2019, but still do not have a publication that people can build a production system against. If we had a road to publication in 2019, there would be production implementations today. Since there was not, there are 'custom' implementations in production, with talk of how they will 'add' support for the standard when it is available. Publication/process should not be such a barrier.

On the other hand, a fixed target provides implementers confidence to actually build things.

Looking at the publication history, FHIR started with rapid iteration. I think that is a competitive advantage that allowed for good feedback and design. Now that FHIR is mature enough to have large implementers of normative content, I think the publication/release/whatever process should be adjusted to account for it. The alternative of 'slow releases' means that newer content cannot benefit from the rapid iterations that made FHIR successful.

Lloyd McKenzie (Feb 28 2022 at 21:45):

@John Moehrke If the community votes down breaking change because it's too painful, FMM becomes moot. As SDO, we don't have the luxury of changing stuff just because we want to once implementation gets far enough along - at least not if we want the community to adhere to our specs.

Richard Townley-O'Neill (Feb 28 2022 at 22:57):

I like option 3. We are in a similar situation to @Simone Heckmann. We will be working with R4 quite a while more, but some of the new R5 features will be useful.

Richard Townley-O'Neill (Feb 28 2022 at 22:57):

Within option 3 some resources could have their FMM level raised to 4 or 5 without the admin overhead of making them normative. Resources that don't make it to FMM 5 can be seen as more risky than those that do.

Richard Townley-O'Neill (Feb 28 2022 at 22:57):

Maybe the candidates for normative in R5 can be triaged and the "cheap enough" ones can be made normative.

Lloyd McKenzie (Feb 28 2022 at 23:59):

Cheap is only in terms of number of ballot cycles. And that cost is driven by comments that result in substantive change - which is always hard to predict. So, if we take anything normative, we should expect an extra quarter or so to publishing timeline.

Grahame Grieve (Mar 01 2022 at 06:13):

I wonder: if we go with option #3, what does it mean to call content normative for the first time?

Grahame Grieve (Mar 01 2022 at 06:13):

I think that the answer is: it's an indication of how we feel

Michael Lawley (Mar 01 2022 at 06:45):

Surely option 3 would preclude making new things normative, and the issue is more about the status of changes to existing normative resources?

Peter Jordan (Mar 01 2022 at 07:03):

My reading of Option 3 is that, as a 'Trial Use' release, it precludes making anything normative for the first time, or changing any content marked as normative in R4.

Michael Lawley (Mar 01 2022 at 07:49):

I would have thought additive / non-breaking changes to R4-normative content would be acceptable as long as the additional elements were tagged as trial-use.

Mike Hamidi (Mar 01 2022 at 14:31):

From my assessment, there are many still working on getting R4 resources built into the ecosystem. I'm sure there was also a rush to get things into R5 which some may have and others did not. Therefore, should R5 be published and have minimal broad implementation? Otherwise, should R5 remain as a step to further mature content and implementation practicality towards an R6? As we know, the industry is mostly cautious, incremental, and has its own checks and balances (e.g., ROV/I, regulatory requirements, strategic roadmaps, so forth). Therefore, I would suggest to appease both sides of spectrum is to release R5 as journey to flesh things out for a much broader implementation solution in R6. At the end, there's a reason why versions exist. Some get used and others do not, but it should not preclude the need to innovate and mature its purpose. Now, the logistical nature of managing multiple versions is another factor onto its own, which I'll leave to others to evaluate.

Lloyd McKenzie (Mar 01 2022 at 14:43):

For option 3, we'll absolutely change normative content (though in a way that maintains compatibility with R4). It's just that all of the changes would be flagged as STU.

Scott Gordon (Mar 01 2022 at 15:00):

Question for Option 3 (Trial Use): would this be FULLY supported by IG creation, SUSHI, servers, etc.? if it's just an "orphan child" that is only partially supported for something like PQ/CMC, I don't know how much better it is than nothing at all.

Lloyd McKenzie (Mar 01 2022 at 15:06):

I'd expect it to be supported by the HL7-published tools and Firely-supported tools as well as all reference implementations. Support by EHRs and other tools would be driven by the market. (That's true regardless of which option we choose.)

Vassil Peytchev (Mar 01 2022 at 15:43):

For #3, I think the following applies:

1. No changes of FMM to normative (or only few?)
2. Changes to current normative content will be present, but called out as STU

What is not obvious, but I think is entirely possible, is that shortly after R5, we can have R5.1 with more normative content, as long as it is not substantially changed from R5. At least I hope that the publishing tools for the release are being improved to make that possible.

Lloyd McKenzie (Mar 01 2022 at 16:11):

I don't think there'd be any plan to follow a 5.0 STU release with a 5.1 normative release. After we put out a release, the intention is to give the community time to adopt it. Interim releases like R4B are quite restricted in what they can change - to maintain full compatibility outside specific domains. (Not sure if we'll see similar circumstances to what drove the most recent R4B again before R6.)

Lloyd McKenzie (Mar 01 2022 at 16:15):

Putting out a plethora of non-fully-compatible releases divides the interoperability community and increases the number of versions systems are being asked to support in parallel. I don't think we'll be able to move to a regular semi-frequent set of updates until most content is normative and we're thus able to make changes in a way that systems can pick them up or not and still interoperate with everyone else.

Vassil Peytchev (Mar 01 2022 at 16:31):

Putting out a plethora of non-fully-compatible releases divides the interoperability community and increases the number of versions systems are being asked to support in parallel. I don't think we'll be able to move to a regular semi-frequent set of updates until most content is normative and we're thus able to make changes in a way that systems can pick them up or not and still interoperate with everyone else.

Completely agree. My suggestion is to have a fully compatible R5.1 release that is nothing like R4B - no new resources, no new datatypes, just the promotion of a few artifacts to normative status if necessary, so that we don't have to rush any to R5, or wait to R6 for any that are ready.

Lloyd McKenzie (Mar 01 2022 at 16:42):

So a branch that would contain only technical corrections to R5 and those changes needed to move resources to normative (which could include some breaking changes). If we were to do that, what would be the value of the R5 release?

Gino Canessa (Mar 01 2022 at 17:04):

Vassil Peytchev said:

... a fully compatible R5.1 release ... no new resources, no new datatypes ...

A lot of WGs are working on things that involve breaking changes: new resources, changes to other resources, etc.. Getting that published is already an issue today - adding a release cycle that specifically prohibits it feels like the wrong direction.

I would prefer something like* breaking the spec releases into two parts: one for mature portions (released every 1-2 years?) and one for 'fast moving' stuff (released every quarter?). It means a bit of extra work in negotiation (e.g., I support R4 Core + 2021-Q1), but it would let the mature parts move slowly and not prevent the rest being worked on. Assuming the actually interoperable parts are normative (or FMM4+ or whatever), it is reasonable to have slow release cycles of that content and pursue broad adoption. The rest is content that is being worked on, but needs a publication process to move to the 'next step'.

*This is one approach of many - I am not particularly invested into any single one. Pros and cons need to be weighed carefully, but I think this process serves well-enough as an example.

Lloyd McKenzie (Mar 01 2022 at 17:39):

Putting out any release that isn't actually taken up by toolsmiths and EHRs is counter-productive. My impression has been that every 1-2 years is about the max speed for toolsmiths and too fast for EHRs. My impression of what the community can reasonably support would be a major release every 3-4 years and an interim release half-way-through for fast-moving stuff that will be supported by tools but will likely not be taken up by much of the community. (Note that the major release won't actually see significant production implementation until about the time that the interim release comes out.

If we were to put out R5 in Q1 2023, it'll be Q4 2024 before apps or other tools can start to take advantage of it. R6 would be 2027 or 2028.

Josh Mandel (Mar 01 2022 at 17:45):

I don't think your assessment (7 quarters of lag between release and availability) takes the full breadth of the community into account, Lloyd. Some of the native FHIR services are entirely metadata driven and can deploy support for new releases immediately, when customer organizations have a reason (e.g., new resources or capabilities) to adopt.

Lloyd McKenzie (Mar 01 2022 at 17:49):

Maybe if we make zero changes to the infrastructure resources and data types. But even then, there's a difference between 'theoretical capacity' and 'how quickly do they want to move?'. The more time the tools spend chasing support for new releases (which to this point at least, have always required tool changes), the less energy there is for net new features.

Gino Canessa (Mar 01 2022 at 17:49):

Lloyd, you make it sound like EHRs implement 100% of a published spec and that is a barrier towards publication. FHIR publication is monolithic, but implementations are not - and they are not only released every 3-4 years. Implementations are incremental based on use-cases, market, etc.

Related, if the publication window works that way the penalty for missing it is extraordinarily high. This causes people to both push things out before they are ready, and to try and squeeze as much as possible into a release (issues which I think we are seeing a lot of right now).

Josh Mandel (Mar 01 2022 at 17:52):

Maybe if we make zero changes to the infrastructure resources and data types.

I mean, sure there's value in stabilizing the infrastructure resources. But with normative status achieved for all of the following, we are theoretically there.

Lloyd McKenzie (Mar 01 2022 at 17:52):

Implementations are released more frequently, but there's a huge incentive to ensure that all of the different implementations are on the same release. Mixing and matching DSTU2, STU3 and R4 for different use-cases doesn't work well. (If this is happening at all in production, it's either super rare or whoever's doing it is being very quiet.) Where there are multiple versions in use, it tends to be via parallel interfaces.

Lloyd McKenzie (Mar 01 2022 at 17:54):

R5 includes changes to the type hierarchy that most metadata-driven implementers consider 'breaking'. Even now we're talking about refactoring how inheritance and interfaces are exposed. That will also drive change. And for most EHR implementers, I don't think metadata-driven works.

Vassil Peytchev (Mar 01 2022 at 17:54):

A lot of WGs are working on things that involve breaking changes: new resources, changes to other resources, etc.. Getting that published is already an issue today - adding a release cycle that specifically prohibits it feels like the wrong direction.

I think there was a wide agreement that if the major releases take 2-3 years, there is a need for faster iteration in some cases. R4B is an anomaly because it was not planned, and a lot of new things were added. I think breaking changes need to be done only in major releases, non-breaking changes can go in point releases for faster iteration. Specifically for the current discussion I ma arguing that the first point release for R5 should be both non-breaking, and non-substantive, with the specific purpose to get almost ready resources to normative status.

Some of the prerequisites for all this is to have the tooling support it, and agree that each major release (up to tow releases back) will have a long-lived branch.

Josh Mandel (Mar 01 2022 at 17:56):

I think breaking changes need to be done only in major releases,

Can you clarify whether you mean only in new publication versions ("4.0" -> "4.3" is -- confusingly -- already a major release, per our versioning conventions)?

Lloyd McKenzie (Mar 01 2022 at 17:57):

Frequent releases that don't break things doesn't really fix anything or add new capability - so what's the point?

Josh Mandel (Mar 01 2022 at 17:58):

If I hear Vassil's perspective correctly, the "point" is locking in consensus on things that turn out to be working well.

Grahame Grieve (Mar 01 2022 at 18:00):

But with normative status achieved for all of the following, we are theoretically there.

@Josh Mandel well, there's some obvious exceptions that I sweat over: ConceptMap, and List. Vocab has made breaking changes to ConceptMap which are going to hurt for quite a while.

Josh Mandel (Mar 01 2022 at 18:03):

This is fair, but I suspect many servers offer metadata-driven FHIR APIs for R2/R3/R4 without any special built-in treatment of ConceptMap.

Gino Canessa (Mar 01 2022 at 18:13):

Again Lloyd, the compatibility issue only exists for low-maturity resources, which are not widely adopted (by definition?).

Since Patient is normative, an R4 and R5 version are compatible. Perhaps R6 would introduce something breaking (who knows), but that is my point - as long as the "mature" resources do not change, the compatibility story is different. I expect trivial effort for a vendor supporting a version of US Core in R4 to support the same version in R4B or even R5. The effort comes when the next version of US Core needs something that was not a stable candidate in R4 and thus is new effort. That will be true regardless of which FHIR release is current at the time.

Similarly, I do not expect large EHR vendors have implemented many resources at FMM0. So, a release that breaks something at that level doesn't affect them because they have not implemented it.

But with that in mind, there are use-cases that need specific things that are low maturity. E.g., vendors are implementing custom subscription solutions because of the delay in publication. I imagine the same happens for almost any resource - it is being added because somebody needs it. The sooner those items get published, the sooner adoption can pick up, revisions can happen, and maturity can progress.

For a relevant reference - DICOM is published 4-5 times per year. With so much of the spec stable, it is a non-issue. People update to the latest when they have a use case that needs it, but long-term compatibility is the expectation.*

*In fairness, the DICOM model uses UIDs for 'resources' and can just retire old ones - so an old profile of an MR does not prevent a new profile for MR. I think an equivalent would be pinning Patient to its normative release (e.g., Patient_R4), and then even when R5 was published you would still use Patient_R4 until there was a definition that superseded it.

Lloyd McKenzie (Mar 01 2022 at 18:22):

There are only two 'clinical' resources that are normative - Patient & Observation. Changes to things like AllergyIntolerance, Procedure, Practitioner, etc. are where the interesting thing is happening.

Supporting R4B should indeed be trivial. Supporting R5 will be a significant lift because lots of resources in US Core have breaking and/or substantive changes in R5

Lloyd McKenzie (Mar 01 2022 at 18:25):

Group, List, ImplementationGuide and lots of other widely implemented resources are at maturity level 1. I don't think maturity drives implementation so much as utility.

Lloyd McKenzie (Mar 01 2022 at 18:25):

I agree that once we get to a state where most resources are normative, we can update regularly. We're just not there yet.

Gino Canessa (Mar 01 2022 at 18:34):

Fair enough, but without updating those things regularly we won't get there (or at least, it will take decades instead of years).

If resources are in production use, lock them down. Additional use cases can add to or create new resources.

Lloyd McKenzie (Mar 01 2022 at 18:39):

If things hit FMM 1, we expect them to be in production use - and there are loads of resources that are FMM 0 that are in production use. So essentially everything will be 'locked down' in that breaking changes will hurt someone.

Lloyd McKenzie (Mar 01 2022 at 18:40):

And we certainly don't want new resources created where existing ones can meet the use-case (but breaking changes are required to do so)

Josh Mandel (Mar 01 2022 at 18:42):

That feels like a rule of thumb, but it's not a situation we've had to grapple with yet, and analysis would have to take the particulars into account.

Gino Canessa (Mar 01 2022 at 18:54):

If things hit FMM 1, we expect them to be in production use ...

In Maturity Levels, the first one that mentions production is FMM 5, so I think there is a disconnect there... But it actually doesn't matter for my point of view.

I am not trying to argue where a maturity line should exist, simply that there is a difference between mature resources where widespread adoption and interop is realistic and immature resources where rapid publication/feedback/modification is necessary.

Those two perspectives are in conflict, and processes that do not address that are going to make somewhere between many and every person unhappy.

When and how items could flow between parts is irrelevant if we do not agree that such a distinction exists and is important enough to address.

Gino Canessa (Mar 01 2022 at 18:58):

(relevant too, I think, is the expectation of an implementer - e.g., an early adopter of FMM 0 resources should expect change, whereas someone implementing a normative resource should expect stability)

edit: The FMM level can be used by implementers to judge how advanced - and therefore stable - an artifact is. (from versions.html)

Vassil Peytchev (Mar 01 2022 at 19:11):

I think breaking changes need to be done only in major releases,

Can you clarify whether you mean only in new publication versions ("4.0" -> "4.3" is -- confusingly -- already a major release, per our versioning conventions)?

Yes, "only in publication versions"

Lloyd McKenzie (Mar 01 2022 at 19:12):

We're not in disagreement around expectations for stability. The question is what implementers will tolerate in terms of the frequency of breaking changes. With a standard, for it to be useful, everyone in a community needs to be using a compatible version of the standard. Which means that if you introduce a release with breaking changes that at least some portion of the community is using, then everyone needs to migrate or everyone ignores the release. Even if you only include the resources in US Core/IPA, there's a lot that, while widely implemented, are not stable from the perspective of the maturity levels or the work groups. If Practitioner underwent breaking changes in one release, Encounter the next, MedicationUsage the next, you're going to find EHRs (and all of the apps and services that sit on top of them) struggling mightily to deal with change every year, let alone every 6 months.

For practical reasons, it's pretty much impossible to get out more than one release every 6 months from HL7. The publication cycle takes that long at a minimum - and that's assuming you're not touching anything that's normative. For something like FHIR Core, it's also a degree of intensity the organization couldn't easily sustain - at least not until we get to the point where we're primarily making technical corrections and tiny tweaks.

Wayne Kubick (Mar 02 2022 at 18:04):

I think Option 3 is the most practical choice moving forward, supporting newer use cases while reducing the burden of backward compatibility. I also think it would be useful to point to R6 as the next planned release with new normative content.

Jens Villadsen (Mar 02 2022 at 19:11):

I'm also for Option 3 perspective. One thing to note though (my own personal experience): The business requirements that my customers have are not fixed to any given FHIR version. Their requirements and needs are there independent of whatever FHIR version their range of systems run. If they have a need and their particular system was recently implemented, they won't spend a dime on updating it to support a more recent standard of FHIR if the new standard doesn't solve any of their requirements. IMHO, the maturity level on the particular resources plays a role, but it aint that big - at least not when reality enters the game. If there is a resource type that fits my customers needs within the specific version of FHIR my client has already chosen/bound to, I will use that resource to solve the needs, more or less regardless of the maturity level.

Paul Lynch (Mar 02 2022 at 21:29):

Under option 3, would IGs be able to update to point at the "Trial Use" changes?

I can see opinion leaning toward option 3, but I would like to put in a contrary vote for option 2. For our SDC IG software, although there are changes in R5 I would like to see finally arrive, of those changes there is nothing for which I can't wait an extra few months, and I prefer implementing less frequent and more stable releases. I don't feel strongly about it, though.

Bryn Rhodes (Mar 02 2022 at 23:17):

CDS WG discussed this today and we took a straw poll, adding that feedback here:
Straw poll: Option #1: 1, Option #2: 0, Option #3: 12

Bryn Rhodes (Mar 02 2022 at 23:17):

(I was the 1 vote for Option 1)

Lloyd McKenzie (Mar 03 2022 at 00:42):

IGs will be able to point at R5, regardless of what it is. However, the ability for IGs to progress to normative will be based on what portion of their profiles can go normative - and generally only profiles on normative artifacts can go normative.

Elliot Silver (Mar 03 2022 at 00:58):

For clarity, when we talk about option 3 as R5 being "trial use", do we mean:

• the entire publication is trial use, or
• we don't progress things to normative beyond what is already normative in R4, and we don't change anything that was normative in R4
• or ...?

Vassil Peytchev (Mar 03 2022 at 01:49):

Since no one corrected my question/definition earlier, I will repeat it here:

1. No new normative content.
2. All new content, including changes to currently normative content, will be marked as STU.

Lloyd McKenzie (Mar 03 2022 at 03:40):

Option 3 means:
a) nothing that isn't normative in R4 becomes normative
b) all changes to R4 normative resources and pages are treated as 'STU'

I don't know that we'll mark all page changes as STU - that'd be difficult and overwhelming to the reader.

Brian Alper (Mar 03 2022 at 11:26):

This idea may be too far off to work (and I don't know the intricacies of the underlying technical requirements to support it) but what if the 'standard version' selected for use could be applied at a Resource level rather than a whole-system version. If FHIR servers could support Resources as defined by their version, then systems could make incremental change as needed for desired implementations instead of whole-scale change for parts of the specification that are not as immediately relevant. Problems move to how to track and account for Resource versions.

Lloyd McKenzie (Mar 03 2022 at 14:31):

One of the core tenets of FHIR is that there's one schema for a FHIR instance that works the same way across the world. Mixing and matching versions breaks that and would seriously damage interoperability. It would also break all reference implementations. Finally, it would require us to bake 'version' into the instances, which we know increases long-term industry costs.

Hans Buitendijk (Mar 03 2022 at 18:01):

We, Cerner, suggest to go option #3. Rationale:

Option #1 is too big a rush and the normative additions would not necessarily be complete/mature enough given the rush while most national initiatives are FHIR R4 based.

Option #2 would push out various updates being available for which there are projects that have an interest, but no need to be normative per se. Additional, there are some changes necessary to normative materials that could be managed as STU updates that would help. Also, there are pre-adoptions from R5 being considered that would then remain uncertain and subject to change.

Option #3 would provide a balance of making available many of the enhancements of interest that do not need normative status, pre-adopt R5 in select areas using extensions that are more likely to provide continuity, and demonstrate progress.

Robert McClure (Mar 03 2022 at 19:53):

Building upon the answers about what #3 means (some of this me just not understanding stuff):

1. Will all the new CI content (changes to R4 or just new) be in the R5 ballot or just parts?
   1.1 If just parts, how are the parts determined?
   1.2 If all the CI content, then is all under ballot or just parts. If just parts, how are those parts identified?

2. Will it be possible to identify which content was intended to go Normative and what was not?

Lloyd McKenzie (Mar 03 2022 at 20:23):

1. All content will be there and all content will be up for ballot regardless of option
2. If we go option #3, then nothing will 'go' normative. For existing pages that are normative, how we'll distinguish normative content from changes that remain STU is up in the air. For resource elements that are net new, we can flag them. For normative elements that have changed or normative pages with substantive changes, we might just include blurb at the top that says something like "While this artifact/page is normative as of FHIR R4, changes introduced in this release are NOT yet considered normative. Click [here] to see differences for this page with the equivalent in R4."

Lloyd McKenzie (Mar 03 2022 at 20:23):

(That last bit hasn't been discussed, but it's my take on how to implement option 3 with the minimum of overhead.

Reuben Daniels (Mar 03 2022 at 22:05):

Vocabulary WG discussed this today and we took a straw poll, adding that feedback here:

Option #1: 5
Option #2: 0
Option #3: 2
Abstentions: 3

Riki Merrick (Mar 03 2022 at 22:19):

OO voted today unanimously to support Option 3 mainly because we have 2 IGs that are built on R5 content, that have finished ballot reconciliation, but cannot be published until R5 is published.
Other thoughts to consider: 
Option 3 should include a firm date for R6 release, so we can work backwards from that
Option 3 gives us more runway to get our resources into better shape for being normative
OO does NOT like Option 2, as it will stop our ability to publish 2 IGs we have ready for publication. 

• here is a link to the minutes: https://confluence.hl7.org/display/OO/2022-03-03+Main
  Riki

Michelle (Moseman) Miller (Mar 03 2022 at 23:41):

Patient Care didn't take a formal vote, but general discussion was leaning towards Option 3.

• PC appreciates having extra time to get AllergyIntolerance and Condition normative (though we did vote to proceed with those resources going normative if Option 1 comes to fruition)
• PC believes there is value in publishing R5 changes to AdverseEvent especially since we've received positive feedback on the build/R5 changes in that resource to date

Jens Villadsen (Mar 04 2022 at 17:48):

Have the affiliates been asked?

Jens Villadsen (Mar 04 2022 at 17:52):

/ notified?

Lloyd McKenzie (Mar 04 2022 at 17:56):

Affiliate reps are generally responsible for sending out solicitations to their own members. I know Canada has done that. I can't speak for the others.

Jens Villadsen (Mar 04 2022 at 18:15):

Who notified affiliate reps?

Lloyd McKenzie (Mar 04 2022 at 19:37):

It was sent to co-chairs, which went to the co-chairs of the international council. They should have sent it out to the affiliate reps. @Ron G Parker?

Peter Jordan (Mar 04 2022 at 20:09):

AFAIA, HL7 on FHIR Posts are distributed to all HL7 International Members and Affiliate Members with HL7 International voting rights (which includes Chairs). The next IC meeting is scheduled for March 16th and this topic will almost certainly be on the Agenda.

Jens Villadsen (Mar 05 2022 at 13:34):

If that is the case, it must have ended up in my spam folder / blocked (because I can't find any mails mentioning this anywhere). I just wan't to make sure all affiliates are informed about this and that they are given a chance to be heard.

Peter Jordan (Mar 05 2022 at 22:22):

I've circulated the HL7 on FHIR Post to the Affiliate Chairs List server.

Michael Lawley (Mar 07 2022 at 01:57):

@Brian Alper We have been doing something like this with Ontoserver - we implement R4, but have "pre-adopted" some R5 features using the version Extensions. It's working for us because we're in a limited domain (terminology resources) and two of the core resources are normative. It may not work for all, and does rely on the expected changes being stable.

John Moehrke (Mar 07 2022 at 18:09):

Security WG discussed this today. There was not strong sentiment the alternatives, but there is an interest to get a release of R5 available to enable IG work using the newer flavors of AuditEvent and Provenance. --> Option 3.

Kevin Power (Mar 08 2022 at 21:57):

Clinical Genomics discussed on our call today and took a straw poll.

Feedback:
CG is not really affected but does appreciate the extra time to clean up our MolecularSequence resource.
We would like to learn more about specific dates for any of the options, especially freeze dates for changes.
Much opposition to Option 1.

Poll:
Abstain: 6
Option 1: 0
Option 2: 5
Option 3: 5

Notes here:
https://confluence.hl7.org/display/CGW/CG-2022-03-08#CG20220308-Topic1:R5DeadlineUpdate

Grahame Grieve (Mar 09 2022 at 05:57):

THanks all for the feedback. Opinion has been strongly in favour of option #3 but not unanimous.

now we have to figure out whether is a procedurally correct way to do option #3

Felipe Soriano (Mar 22 2022 at 07:38):

Option #1.. I think in Software Engineering it's common sense: software has validity! Adaptation of a specification will never be immediate. However, the requirements are the main responsible for the depreciation of a software. A pandemic is a very strong reason for new requirements. The R4 version may still be supported, but we need to evolve... Clouds deprecate non-LTS language versions and we adapt to the new version. I think open source also has to follow the needs and be the engine of change. This is just my opinion. Thanks.

Felipe Soriano (Mar 22 2022 at 07:57):

However, I think Semantic Versioning is very important to avoid impacts. I believe that a feature should come out of an R5 release only after being marked as Deprecated in an R4 release. And those that have undergone changes enter as Trial Use. I don't think I'd see it be that extreme in the changes. Change major version only when there is something that breaks the previous API.

Peter Bernhardt (Mar 30 2022 at 15:42):

Any update on Option #3, @Grahame Grieve ? FWIW, I favor it.

John Moehrke (Mar 30 2022 at 16:01):

see #Announcements - https://chat.fhir.org/#narrow/stream/179240-Announcements/topic/R5.20Roadmap

---

Last updated: Apr 12 2022 at 19:14 UTC