Stream: implementers
Topic: Release 3 progress
Grahame Grieve (Mar 16 2017 at 11:17):
I have upgraded the trunk/current build to version 3.0.0, which is the version release 3 will be released under. We have entered the final freeze, so there are no more substantiative changes allowed (well, in principle).
Grahame Grieve (Mar 16 2017 at 11:18):
Thisi is the version that reference implementers should use to get into gear for the final release which is planned to happen Mar 21st
Grahame Grieve (Mar 16 2017 at 11:54):
fhir3.healthintersections.com.au is now upgraded to this version
Brian Postlethwaite (Mar 16 2017 at 13:19):
And for those that want to try out the dotnet fhir client, the source is now updated on gthub to, refer to the dotnet channel for details.
Eric Haas (Mar 16 2017 at 19:38):
Heads up that once it is published STU3 will use the base http://hl7.org/fhir
as the Current Official Published Version which currently DSTU2 with 1 technical errata.
-
DSTU2 will still be available at
http://hl7.org/fhir/DSTU2
-
STU3 will also be published at
http://hl7.org/fhir/STU3
If you have DSTU2 based IGs or other artifact that reference the base you may have to update them.
Eric Haas (Mar 16 2017 at 23:41):
From @Kevin Olbrich re: urls for published documents. If I might make a suggestion, publishing the documents at something like http://hl7.org/fhir/2.0.0 and then putting a redirect at http://hl7.org/fhir/STU3 -> http://hl7.org/fhir/2.0.0 would help folks move in the direction of having one and only one way to refer to the version of FHIR. As it stands now people have to do a mental map from 2.0.0 -> STU3 and it's not easy to find the documents for 1.8.0 unless you happen to know that it was in Jan of 2017.
Grahame Grieve (Mar 16 2017 at 23:56):
I'm intending to do that with the big website update when I release
Brian Postlethwaite (Mar 17 2017 at 01:30):
In terms of reference server availability, my server is now operational at http://sqlonfhir-stu3.azurewebsites.net/fhir (this utilizes the dotnet fhir client which is available on github that was updated last night)
Grahame Grieve (Mar 20 2017 at 01:05):
hey all. Release 3 is very nearly done - the editors have been working unbelievably hard to get all the QA done. The current copy is nearly gold: http://build.fhir.org
Grahame Grieve (Mar 20 2017 at 01:05):
anyone who has time is invited to spend what they have in the next 3 hours or so checking it out, looking for problems
Richard Ettema (Mar 20 2017 at 01:52):
@Grahame Grieve I noticed that there are a few Patient example resources that contain an incorrect STU3 code system for the Patient.contact.relationship. It's still the DSTU2 code system. For example, the patient-example.xml contains:
<relationship> <coding> <system value="http://hl7.org/fhir/patient-contact-relationship"/> <code value="N"/> </coding> </relationship>
should be the V2 code system http://hl7.org/fhir/v2/0131:
<relationship> <coding> <system value="http://hl7.org/fhir/v2/0131"/> <code value="N"/> </coding> </relationship>
Is this something I can update and commit?
Richard Ettema (Mar 20 2017 at 01:54):
Looks like there are 5 Patient example resources with this issue.
Brian Postlethwaite (Mar 20 2017 at 01:55):
I thought I got all those udpated. And the validations had been tightened up for that.
Richard Ettema (Mar 20 2017 at 01:58):
The ValueSet for this is marked Extensible. That may let the validation pass.
Grahame Grieve (Mar 20 2017 at 02:00):
I had to wind that validation back - there's sooo many failures related to that
Grahame Grieve (Mar 20 2017 at 02:00):
specially in the FM resources
Grahame Grieve (Mar 20 2017 at 02:01):
@Brian Postlethwaite if you ficx them and clean build, then please commit them
Richard Ettema (Mar 20 2017 at 02:01):
The problem I see is that the code values appear to be from the STU3 code system but the DSTU2 code system is specified.
Richard Ettema (Mar 20 2017 at 02:02):
Ok. I'll fix locally and if my local build is clean I'll commit.
Richard Ettema (Mar 20 2017 at 02:15):
My local build just finished clean. I'll commit my updated Patient example resources.
Richard Ettema (Mar 20 2017 at 02:52):
Brian pointed out to me 2 other example resources for RelatedPerson that have the same issue. I've updated them and am running another local build before committing them.
Richard Ettema (Mar 20 2017 at 03:01):
Local build is clean; committing changes.
Richard Ettema (Mar 20 2017 at 03:21):
@Grahame Grieve The FHIR Overview - Developers page, overview-dev.html, shows the HTTP response header ETag values without the weak prefix; e.g. ETag: "1"
. The use of the weak prefix is a SHOULD per the definition at http://build.fhir.org/http.html#versioning.
Should these examples of ETag be updated to show the weak prefix; e.g. ETag: W/"1"
?
Grahame Grieve (Mar 20 2017 at 03:22):
hmm. what is my server doing now?
Grahame Grieve (Mar 20 2017 at 03:24):
I am using W/ - so, please change and commit
Richard Ettema (Mar 20 2017 at 03:24):
Just did a read of Patient/example on your server. You returned the weak ETag -- ETag: W/"1"
Richard Ettema (Mar 20 2017 at 03:24):
Ok. Will do.
Last updated: Apr 12 2022 at 19:14 UTC