Stream: netherlands
Topic: nl-core for STU3?
Marc de Graauw (Mar 15 2017 at 09:36):
nl-core is not compatible with STU3 - if only because of fhirVersion="1.0.2"? Any other known incompatibilities? And are there plans for a STU3 version?
Alexander Henket (Mar 15 2017 at 15:10):
Yes there are. As soon as Simplifier is ready we will mass convert all DSTU2 contents to STU3. We'll have to deal with what we find, but in principle no content changes are expected. The only changes within expectation are the ones that are necessary for STU3 compliance.
.
You sent me a private email that I'd like to post here too, because it pertains to work of @Ben Schrijver and potentially to @Theo Stolker as they are already working with STU3. Fellows please note that your profiles are currently invisible to us.
.
Translated from your email:
"I've made a private conversion of the DSTU2 nl-core profiles to STU3. Most is straight forward, but here are some open issues:
.
1- Examples need labels in STU3, and did not add those yet, so they are in comments for now
2- Constraints are in comments, because I did not get to converting those to Fluentpath. I don't get why Fluentpath is not optional rather than required
3- Not all Element.ids are unqiue right now. Schema doesn't complain but seems in error to me, e.g. Organization.extension. What's the strategy here? Organization.extension.1 and Organization.extension.2 for example?
4- Added derivation value="constraint" everywhere, otherwise the schema complains. But sometimes profiles might be a specialization, or a combination.
5- What is the new caonical URI for the STU3 profiles? Something like "http://fhir.nl/fhir3/StructureDefinition/nl-core-organization"?"
.
These all good points. I've set up a mass conversion locally, and will be going through that route, unless Simplifier offers this (it already offers a number of services like that). This is something MedMij will be doing in cooperation with Furore.
.
1. I think I'll mass add labels with fixed text "example" and update them to something more useful over time
2. I believe we have already the Fluentpath expressions in an extension present, so I'm not too worried yet, but we will need to check
3. That is most definitely a bug in the DSTU2 profiles then that we need to fix
4. I think constraint is a good default. We might need to revisit them by hand
5. We have not decided. I would go a little bit different probably "http://fhir.nl/fhir-stu3/StructureDefinition/nl-core-organization"
This could also be a point in time where we rethink the canonical logic, since we may never end up hosting anything at that URL. I do not have the answer there yet.
Hope that covers a number of your questions.
Marc de Graauw (Mar 15 2017 at 15:39):
3. Is a bug in my conversion, not the DSTU2 profiles. Those had missing element.id, I provided those but was not sure about the strategy for handling duplicates.
Can we decide on 5. soon? Then I can at least already provide the correct URL's from elsewhere in my SD's.
Marc de Graauw (Mar 15 2017 at 15:42):
For the others: here's the link to my efforts. status="very provisional". https://www.dropbox.com/sh/1nyfr4rw8xyjtjf/AAAcbFt2rAHlJEzz3xEIHnIHa?dl=0
Alexander Henket (Mar 15 2017 at 17:43):
I would not know how to decide on my own (although I'd love to :-). Hoping for more input from others here. It'll be during the WGM NL March 30/31 otherwise
Marc de Graauw (Mar 16 2017 at 10:09):
Well, it would be downright silly if I roll out something like fhir-stu3 for IKNL and later fhir_stu3 or something is chosen. Who is involved in the decision? I can't be the case that only the WGM forum can vote, and nothing can be done in between. So here proposal: we use the
"http://fhir.nl/fhir-stu3/StructureDefinition/nl-core-organization" format for STU3 NL core components. Any objections?
Marc de Graauw (Mar 16 2017 at 10:53):
Patient.contact.relationship should come from PatientContactRelationship (Extensible) in DSTU2. From v2 Contact Role (Extensible) in STU3 (1.8.0). nl-core-patient takes it values from HLv3: http://hl7.org/fhir/v3/RoleCode (which seems to violate the idea of "Extensible", since it duplicates codes). What do we do for STU3? Just keeping the v3 list sseems best for backward compatibility with v3 systems.
Marc de Graauw (Mar 16 2017 at 11:05):
Did you get the DSTU2 nl-core components to validate with the FHIR validator? I can't get it done for 1.8.0, I just get validation against Patient itself.
Marten Smits (Mar 16 2017 at 11:29):
If we use the v3 and it duplicated codes from the extensible v2 value set. Then we shouldn't use that.
Marten Smits (Mar 16 2017 at 11:31):
We should create a value set that inludes the v3 codes that extent the v2 set and the v2 set itself if the v2 codes aren't complete for us
Marten Smits (Mar 16 2017 at 11:32):
As for the URL: I suggest we use http://fhir.nl/stu3/StructureDefinition/nl-core-organization
The double "fhir" in the URL hurt my eyes before, now is a good time to get rid of it.
Marten Smits (Mar 16 2017 at 11:34):
We didn't do any profile validation yet on our examples, we are planning to do that once that's build into simplifier (working on it)
Marc de Graauw (Mar 16 2017 at 12:03):
http://fhir.nl/stu3/StructureDefinition/nl-core-organization is fine with me. So then that's the new proposal.
Alexander Henket (Mar 16 2017 at 12:41):
The decision making practice context here are the people behind the profiles. NL-BasicComponents was created by MedMij and under the FHIR AM PSS umbrella.
.
WGM NL is a point in time where we meet again. I wish people would read up here too, but they don't (maybe they're at Zorg&ICT) so that limits our abilities.
Marc de Graauw (Mar 16 2017 at 12:42):
I've updated the contents of https://www.dropbox.com/sh/1nyfr4rw8xyjtjf/AAAcbFt2rAHlJEzz3xEIHnIHa?dl=0
Base url is now: http://fhir.nl/stu3/
All StructDefs, NamingSystems, ValueSets, Examples are schema(tron) valid against 1.8.0. No profile validation done yet. Also tested against Grahame's server, I do get errors on unknown extensions (since the profiel isn't known yet), and Extensible codes (same reason), otherwise looking good.
Marc de Graauw (Mar 16 2017 at 12:44):
@Alexander Henket If we have a decent proposal, I'd be surprised if that were rejected. So let's agree on a proposal with those present here, and hopefully formalize that there. (BTW: what's FHIR AM PSS?)
Alexander Henket (Mar 16 2017 at 12:46):
@Marten Smits the reasoning behind http://fhir.nl/fhir was that if http://fhir.nl were ever used, then you could also host wiki/forum/pages from the root without being burdened by the FHIR end point. I'm not saying I propose to keep it, just reiterating the reason why
Alexander Henket (Mar 16 2017 at 12:48):
Both proposals sound equally fine to me. I'm just saying that we cannot make a decision here. You are of course free to pre-adopt and take the risk. It is not just the URL you will be taking a risk on. It concerns contents too. Your conversion might be great, it might be flawed. We don't know
Marc de Graauw (Mar 16 2017 at 12:55):
Let's discuss the decision making process at the WGM too, then. Luckily it's upcoming now, but between April and November we might need to move too. BTW, on DevDays 2016 some changes to humanname were decided, are those integrated in nl-core?
Marten Smits (Mar 16 2017 at 13:16):
Yes we integrated them in DSTU2 already
Marc de Graauw (Mar 16 2017 at 13:17):
@Marten Smits Great :-)
Marc de Graauw (Mar 16 2017 at 13:26):
All other changes I made were really minor, like changing the order of date and publisher in NamingSystem. Stuff like that.
Marc de Graauw (Mar 16 2017 at 13:29):
Resolution will stay a problem. Tools (FHIR validator, servers) will be looking at http://fhir.nl/fhir or /stu3 for profiles. If those aren't hosted there, the profile in meta can't be resolved. So either you'd need the profiles there, or a way to tell tools where the profiles actually live. @Marten Smits Any idea how Simplifier does / is going to handle this?
Marten Smits (Mar 16 2017 at 13:33):
Well, simplifier is a FHIR server. So currently you can get your profile by using https://simplifier.net/api/fhir/StructureDefinition?url=http://fhir.nl/fhir/StructureDefinition/nl-core-organization
Marc de Graauw (Mar 16 2017 at 13:47):
Yes, but if I have a file with meta.profile="http://fhir.nl/fhir/StructureDefinition/nl-core-organization" and use Simplifier to validate that, will Simplifier know where to pick up the profile? You said: "We didn't do any profile validation yet on our examples, we are planning to do that once that's build into simplifier", so I was wondering how that will work.
Marten Smits (Mar 16 2017 at 14:44):
Yes, it will look in simplifier first, if it isn't present it will try to resolve the url
Marc de Graauw (Mar 17 2017 at 09:35):
The url situation is more complicated, it seems. FHIR itself - according to Eric Haas - "once it is published STU3 will use the base http://hl7.org/fhir". And have DSTU2 an DSTU3 variants. If we follow that convention - as I think we should, since it would be really confusing if fhir.nl did differently from fhir.org - then fhir.nl would automatically become the base for STU3 artefacts, and the NL DSTU2 artefacts need updating (which they do anyway, since they refer to fhir.org StructDefs, and those references will be broken once STU3 is released).
Alexander Henket (Mar 17 2017 at 09:37):
The URL hl7.org/fhir holds the active version. Any version also has a permalink. E.g. http://hl7.org/fhir/DSTU2/index.html
Alexander Henket (Mar 17 2017 at 09:38):
There is absolutely no need to follow the hl7.org conventions, but we could if it fits
Alexander Henket (Mar 17 2017 at 09:43):
If we were to follow hl7.org convention we could opt to go for http://fhir.nl/fhir/STU3/nl-core-organization
Alexander Henket (Mar 17 2017 at 10:23):
In hindsight you could say that we 'forgot' to deal with FHIR versioning in the original/current canonical URLs. If we had thought of FHIR versioning from the start, I reckon we had used:
.
http://fhir.nl/fhir/DSTU2/nl-core-organization or http://fhir.nl/fhir/DSTU2/StructureDefinition/nl-core-organization
alas we currently used:
http://fhir.nl/fhir/StructureDefinition/nl-core-organization
.
But... that's not all. You have to version for the FHIR version you are bound to and the lifecycle of the profile. You could say that you only cater for the latter. If you choose that route you do not make the FHIR version explicit in the URL. If you choose the former, you apparently have 1 profile version per FHIR version.
.
I think you need to assume that we will need >1 versions of your profile on the same FHIR version. I think that including your FHIR version apparent in the URL is also beneficial. So in conclusion I think this form could work for the FHIR version:
.
[base]
http://fhir.nl/fhir/ for DSTU2 based profiles (respecting the current state of affairs)
http://fhir.nl/fhir/STU3 for STU3 based profiles
http://fhir.nl/fhir/release4 ...
.
And this for the lifecycle version:
.
[base]/[profile name]-[version]
Marc de Graauw (Mar 17 2017 at 11:28):
Pfff, it's complicated. I don't like FHIR's decision to make hl7.org/fhir point to STU3 once that's released. For instance, nl-core-patient contains:
<base value="http://hl7.org/fhir/StructureDefinition/Patient" />
and when that suddenly points to STU3, that means that technically the current nl-core resources are broken overnight.
If we follow your proposal, then soon:
http://hl7.org/fhir/ points to STU3
http://fhir.nl/fhir/ points to DSTU2
Given the point about being broken overnight, it might be best to repair the state of affairs. And use urls containing STU3 or DSTU2 everywhere.
Marc de Graauw (Mar 17 2017 at 11:32):
Other than that, I think following Alexander's proposal is best. Having:
http://fhir.nl/fhir/DSTU2
http://fhir.nl/fhir/STU3
mirrors:
http://hl7.org/fhir/DSTU2
http://hl7.org/fhir/STU3
If the double 'fhir' hurts the eyes, that's simply a consequence of having fhir.nl as base, nothing to be done about that.
Marc de Graauw (Mar 17 2017 at 11:35):
Except choosing http://hl7.nl/fhir as base. That would enable us to have a new situation in line with hl7.org practices, and leaving fhir.nl/fhir untouched...
Alexander Henket (Mar 17 2017 at 13:19):
It's possible that the (canonical) URL for FHIR core profiles wasn't thought through properly either... For example the Vision Prescription profile at http://hl7.org/fhir/visionprescription.profile.xml.html is DSTU2 today and STU3 in 2 weeks. Its canonical is currently "http://hl7.org/fhir/StructureDefinition/VisionPrescription". I'm not convinced these go to "http://hl7.org/fhir/STU3/StructureDefinition/VisionPrescription" upon update in 2 weeks time so it is impossible to tell from the canonical what FHIR version it binds to. I'm sure Lloyd/Grahame would say that's because the canonical points to the logical intention and that the FHIR version doesn't matter at that level. That is at least what I understood from a similar discussion around ValueSet.url
Alexander Henket (Mar 17 2017 at 13:28):
Reposted question here: https://chat.fhir.org/#narrow/stream/implementers/subject/StrucDef.2Eurl.20and.20base
Michael van der Zel (Mar 18 2017 at 19:31):
@Alexander Henket A question about "http://fhir.nl/fhir" vs "http://fhir.nl". Why not use "http://hl7.nl/fhir"? How are other countries handling this?
Alexander Henket (Mar 19 2017 at 08:51):
We could have chosen that but fhir.nl seemed to have a nice ring to it. Domain is owned by HL7 NL btw.
Alexander Henket (Mar 19 2017 at 08:52):
Note that it's questions like these that keeps me thinking that oids are much much better for the fact that they are not readable. :-)
Marten Smits (Mar 20 2017 at 09:47):
Ceterum censeo Carthaginem esse delendam
Ben Schrijver (Mar 20 2017 at 13:21):
To add to Michael: I personally would prefer hl7.nl/fhir. How other countries are handling this seems mixed. For exampIe I see: http://hl7.org/fhir/us/core/, http://fhir.hl7.org.au/fhir/base/ and http://fhir.de/ I thinks this is a shame, as more consistent naming would've been nice.
Grahame Grieve (Mar 21 2017 at 04:31):
I'm posting the new version now.
Grahame Grieve (Mar 21 2017 at 04:32):
we haven't changed the URLs to be for a specific version. That doesn't mean that we won't - we haven't discussed it. There was just not point talking about a really big decision like that right at the end of the post process, since there was no way I would let any change of that nature happen for process reasons
Grahame Grieve (Mar 21 2017 at 04:33):
note that we have always said that once normative, version won't matter, and before then, people have to figure out how to deal with it before that.
Grahame Grieve (Mar 21 2017 at 04:34):
if there's a better answer, we can talk about it.
Marc de Graauw (Mar 21 2017 at 07:51):
@Grahame Grieve Having STU3 is way more important than the url-versioning issue :-)
Since STU3 is (almost) out, and canonical url's remain the same, I'm reverting my position. I suggest we do the same, and keep "http://fhir.nl/fhir/StructureDefinition/nl-core-patient" (and others) as the canonical url's. Yes, that means users will have to find out how to resolve those correctly for DSTU2 and STU3, but since the canonical in baseDefintion will stay "http://hl7.org/fhir/StructureDefinition/Patient" for both DSTU2 and STU3 they will have to do some figuring about canonical url resolution anyway. If hl7.org/fhir and fhir.nl had different policies, that would just make things really complex.
Until something 'lives' at the end of "http://fhir.nl/fhir/StructureDefinition/nl-core-patient", having http://fhir.nl/(DSTU2 | STU3)/StructureDefinition/nl-core-patient does not really offer any advantages.
Alexander Henket (Mar 21 2017 at 15:01):
FHIR Core may or may not be normative by itself. Our profiles are to be normative and thus treat STU3 as normative.
While it is true that STU3 != Normative, I believe that implementations do not necessarily follow that pattern. We sure have stuff to talk about next week in the WGM NL
Simone Heckmann (Mar 21 2017 at 20:25):
We (Germany) have chosen http://fhir.de for mostly political reasons as we are going to have stuff under that domain that is not primarily authored by hl7.de (e.g. we'll use many valueSets coming from other organizations) and we want to keep our stuff on "neutral ground" so-to-speak.
Alexander Henket (Mar 21 2017 at 20:26):
Who owns fhir.de then? In our case that's hl7.nl
Simone Heckmann (Mar 21 2017 at 20:27):
actually, I do. but I've donated it to hl7.de :)
Simone Heckmann (Mar 21 2017 at 20:28):
We'll change that, eventually.
Alexander Henket (Mar 21 2017 at 20:28):
Haha. Same here. I registered fhir.nl and donated it to hl7.nl
Alexander Henket (Mar 21 2017 at 20:29):
My employer still regrets my donation :-)
Simone Heckmann (Mar 21 2017 at 20:29):
Remember: with great power comes great responsibility :D
Alexander Henket (Mar 21 2017 at 20:30):
That's why gave it to hl7.nl as fast as I could even before my amazement that the domain was free, was over.
Rob Mulders (May 06 2017 at 09:06):
And as member of the board at HL7 NL, I am still very thankful to you for that, Alexander!
Last updated: Apr 12 2022 at 19:14 UTC
