Stream: implementers
Topic: References in national profiles
Øyvind Aassve (Aug 16 2021 at 07:14):
@Alexander Henket @Stefan Lang @Simone Heckmann @Brett Marquard
Hi, in Norwegian basis/ core (no-basis) profiles we have been referencing other resources through other no-basis-profiles - Reference(no-basis-Xyz) - for resources where no-basis profiles exist. As we are developing no-basis-profiles as the according FHIR-resources are being adopted in Norway this is a continuously moving target, and once we have approved a new one all previously no-basis-profiles referencing the new resource needs to be updated. This requires additional governance processes and resources. In practical implementations it will very often not be no-basis-profile that is referenced in the actual implementation, but one that is derived from no-basis (in the same way no-basis profiles are derived from international resources) .
We are discussing whether it would be easier and just as effective to just reference the international resources directly – Reference(Xyz), but we see this is not a common approach. What would be the most important drawbacks with such a solution?
sandeep diddi (Aug 16 2021 at 07:36):
Can we implement FHIR loaded on ADF ? has anyone done this
sandeep diddi (Aug 16 2021 at 07:36):
I am referring
to https://github.com/hansenms/FhirLoader
Øyvind Aassve (Aug 16 2021 at 10:20):
@sandeep diddi - should this be in a different thread?
sandeep diddi (Aug 16 2021 at 10:23):
@Øyvind Aassve Thanks for that i have opened a new thread
Poonam Kariya (Aug 16 2021 at 11:08):
We have web application and we want to set up this smart healthcheck framework for all application users
from where we will get the QR codes? of our application users.?
Jose Costa Teixeira (Aug 16 2021 at 12:49):
@Øyvind Aassve I don't know if I understand the issue you mention, but in Belgium the current idea is:
- We have the BE-core layer, and topic-specific layer (e.g. be-AllergyIntolerance) and on top of that we can have project-specific or vendors-specific layers
- All of those are versioned. When we publish a new version of a higher layer, we need to point to a specific version of the lower layer (or else we need to recheck and re-release the top layers whenever the lower layers change.
- Like FHIR, our versions are published and have a canonical URL but also version-specific urls.
Øyvind Aassve (Aug 16 2021 at 13:15):
@Jose Costa Teixeira - the question we are pondering is whether we should move from this kind of references in national base profiles
Patient.managingOrganization Σ 0..1 Reference(Organization| no-basis-Organization)
and instead only use this:
Patient.managingOrganization Σ 0..1 Reference(Organization)
We organize our profiles into use-case independens no-basis-profiles, use-case specific no-domain-profiles, and implemented profiles (as presented on Devdays in November). https://www.youtube.com/watch?v=8pv-Zztibyg
Lloyd McKenzie (Aug 16 2021 at 13:34):
If you're going to list a choice of target types, they have to be mutually exclusive. Because, by definition, no-basis-Organization is going to be a valid constraint on Organization, Reference(Organization| no-basis-Organization) isn't legal and will give you validator issues.
You could look at using Global profiles in your implementation guide. If a profile is declared as 'global', that means any place you see a reference to the specified data type or resource that is not profiled, then the global profile applies.
Lloyd McKenzie (Aug 16 2021 at 13:36):
@Poonam Kariya - try to always change the topic to something relevant if you're making a new post so avoid getting lost in the ongoing conversation. In this case, you'd be best asking on #smart/health-cards
Øyvind Aassve (Aug 16 2021 at 14:06):
@Lloyd McKenzie - the base-profiles are in this context more logical constructs which communicates what are the reusable structures at the national level and are not made primarily to be validator proof. In a practical implementation most likely it will be an even more constrained version of the profile that is being used. So we are thinking to differ between Reference(Organization| no-basis-Organization) is not really that important. The most important information in no-basis-profiles are terminology binding, identifiers, important national extensions etc. But we do see that most countries (nl, uk, us, de) who are developing base/ core profiles are using other base/core-profiles in the referencing - instead of just referencing the resource like this Reference(Organization).
Lloyd McKenzie (Aug 16 2021 at 15:26):
From a practical perspective, the base-profiles have to be 'true' profiles. They can't be logical models. And in this case, no-basis-Organization would be a profile on Organization. An actual instance pointed to that was valid against no-basis-Organization would also be valid against Organization, and that's not allowed.
Øyvind Aassve (Aug 16 2021 at 15:55):
Good point @Lloyd McKenzie , we have not been entirely consistent in expressing these references. Maybe the question rather should be: is it as good to use reference to a resource when referencing in national base profiles - "Patient.managingOrganization Σ 0..1 Reference(Organization)", or is it better to reference a national base profile if that exists for the resource "Patient.managingOrganization Σ 0..1 Reference(no-basis-Organization)". The latter produces more maintenance, and actual implemented profiles are in any case more restricted then the base profiles.
Note - we have national guidelines that requires building implemented profiles on national base and domain profiles where they exist, so it is in any case asumed that the implemented profiles are in accordance with national profiles. .
Lloyd McKenzie (Aug 16 2021 at 16:03):
I'll turn the question around and ask - what are your expectations of implementers? Do you expect all references to organizations to adhere to your base profile? If so, then you should enforce that - either by setting them as 'global' or by updating your references.
Øyvind Aassve (Aug 16 2021 at 17:04):
Thanks Lloyd, we do expect that. Ill check up on "global" which we have not looked into and might be a better option with regards to maintenance. The issue is that we have been producing 2-5 new national base profiles per year and they go into national standards governance. If we have to update a chunk of our existing profiles with new references ever time we publish a new base profile time and man hours are flying fast :dollars: . Adherance to base profiles are also required outside the base profiles in a set of principles for FHIR profiling.
Lloyd McKenzie (Aug 16 2021 at 17:12):
Global should be much easier. No need to touch the profiles, just add the new ones to your 'global' list in the base IG.
Jose Costa Teixeira (Aug 16 2021 at 17:13):
in Belgium our perspective is so far is that systems must be conformant to the core profiles (like be-patient)
Øyvind Aassve (Aug 16 2021 at 17:20):
@Jose Costa Teixeira - how do you express that with regards to the use of References in your base profiles?
Jens Villadsen (Aug 16 2021 at 17:23):
@Øyvind Aassve feel free to reach out if you want the man hours to go even faster :sunglasses:
@Jose Costa Teixeira are you also using global profiles or do you update the IG's almost continuously?
Jose Costa Teixeira (Aug 16 2021 at 17:58):
we check the IGs when there is a new release (not when there is a change in the CI-build, because that is a preview / WIP) at this moment we don't use version - we just say "be-patient, latest officially published version)
Jens Villadsen (Aug 16 2021 at 18:05):
@Jose Costa Teixeira you know ... we could actually build some tooling for that ;)
Øyvind Aassve (Aug 16 2021 at 18:07):
@Jose Costa Teixeira - from be-patient, how do you make reference to other resources ex Patient.managingOrganization Reference (xyz). Do you prefix organization with be?
Jens Villadsen (Aug 16 2021 at 18:09):
(my guess is this:)
image.png
Jens Villadsen (Aug 16 2021 at 18:09):
from http://build.fhir.org/ig/hl7-be/be-core/StructureDefinition-be-patient.html
Jens Villadsen (Aug 16 2021 at 18:09):
explicitly
Jens Villadsen (Aug 16 2021 at 18:48):
@Lloyd McKenzie shouldn't 'global' also be documented here? https://confluence.hl7.org/display/FHIR/Implementation+Guide+Parameters
Lloyd McKenzie (Aug 16 2021 at 20:02):
It's not a parameter - it's a separate element.
Jose Costa Teixeira (Aug 16 2021 at 21:31):
correct @Jens Villadsen. We refer to the profiles in each profile that uses it.
Jose Costa Teixeira (Aug 16 2021 at 21:32):
Øyvind Aassve said:
Jose Costa Teixeira - from be-patient, how do you make reference to other resources ex Patient.managingOrganization Reference (xyz). Do you prefix organization with be?
IF we have a be-organization profile and we say "in this profile, we need to use the be-organization", then we just do it.
Jose Costa Teixeira (Aug 16 2021 at 21:33):
We could as well have a be-foreign-patient (a profile that represents people that get care in Belgium but are not registered citizens), in which case the managingOrganization could be an Organization, not a be-Organization.
Richard Townley-O'Neill (Aug 17 2021 at 02:05):
Lloyd McKenzie said:
If you're going to list a choice of target types, they have to be mutually exclusive. Because, by definition, no-basis-Organization is going to be a valid constraint on Organization,
Reference(Organization| no-basis-Organization)isn't legal and will give you validator issues.
I thought that Reference(Organization| no-basis-Organization) used targetProfile and so overlapping profiles were permitted. The definition includes
Used when the type is "Reference" or "canonical", and identifies a profile structure or implementation Guide that applies to the target of the reference this element refers to. If any profiles are specified, then the content must conform to at least one of them.
Lloyd McKenzie (Aug 17 2021 at 02:08):
Maybe I'm mis-speaking, but I can remember running into problems with this with the validator. @Grahame Grieve ?
Thomas Tveit Rosenlund (Aug 17 2021 at 06:14):
Richard Townley-O'Neill said:
Lloyd McKenzie said:
If you're going to list a choice of target types, they have to be mutually exclusive. Because, by definition, no-basis-Organization is going to be a valid constraint on Organization,
Reference(Organization| no-basis-Organization)isn't legal and will give you validator issues.I thought that
Reference(Organization| no-basis-Organization)used targetProfile and so overlapping profiles were permitted. The definition includesUsed when the type is "Reference" or "canonical", and identifies a profile structure or implementation Guide that applies to the target of the reference this element refers to. If any profiles are specified, then the content must conform to at least one of them.
I can confirm that we use targetProfiles to define these References. The way a read the documentation for choice of references in targetProfile/Profile, overlapping profiles are alowed. I can not remember this being a problem in my validation efforts on the no-basis profiles using both .NET and Java validator.
If there is any documentation stating the different choices of targetProfiles have to actually be mutually exclusive, we certainly have to change this as our no-basis profiles are not. But I suspect this will be the case for a lot of profiles that use this practice.
Øyvind Aassve (Aug 17 2021 at 07:47):
@Ward Weistra - can you say a little bit about how we possibly can use the Global-element in the IG resource in our national profiles?
Øyvind Aassve (Aug 17 2021 at 07:49):
in Simplifier :)
Lloyd McKenzie (Aug 17 2021 at 15:56):
No clue if Simplifier supports ImplementationGuide.global. But you'd just add something like this to your IG:
"global": [{
"type": "Observation",
"profile": "http://something.org/StructureDefinition/no-basis-Organization"
}]
Lloyd McKenzie (Aug 17 2021 at 15:57):
That would say "any place in this IG you see a target profile of "http://hl7.org/fhir/StructureDefinition/Organization", treat it as if it said "http://something.org/StructureDefinition/no-basis-Organization" instead.
Jens Villadsen (Aug 17 2021 at 16:31):
@Øyvind Aassve as an alternative you could try gofsh and reverse your profiles to FSH and then throw sushi at it and see the results
Alexander Zautke (Aug 17 2021 at 18:09):
Øyvind Aassve said:
Ward Weistra - can you say a little bit about how we possibly can use the Global-element in the IG resource in our national profiles?
@Matthijs van der Wielen
Matthijs van der Wielen (Aug 18 2021 at 18:56):
@Øyvind Aassve stepping in for Ward here. Unfortunately, we currently do not have the functionality that supports ImplementationGuide.global. I was unaware of this functionality so I had to read up on this :grinning_face_with_smiling_eyes: . This would be a very nice feature to have, but I can't make any promises. I will create a Service Desk ticket for you so I can update you on our thoughts and progress of this feature.
Jens Villadsen (Aug 24 2021 at 11:26):
Lloyd McKenzie said:
That would say "any place in this IG you see a target profile of "http://hl7.org/fhir/StructureDefinition/Organization", treat it as if it said "http://something.org/StructureDefinition/no-basis-Organization" instead.
Does the IG publisher infer the target profiles stated in global on the profiles that are part of an IG?
Jens Villadsen (Aug 24 2021 at 11:29):
Because it doesn't seem to be the case
Grahame Grieve (Aug 24 2021 at 12:55):
no that's on the todo list
Jens Villadsen (Aug 24 2021 at 13:31):
how far up on the todo list?
Øyvind Aassve (Oct 18 2021 at 14:38):
@Lloyd McKenzie @Jens Villadsen @Jose Costa Teixeira @Alexander Henket FYI - HL7 Norway Technical Steering Commitee decided Friday to suspend the practice of refering to other no-basis-resources from no-basis-profiles. As example we move from Procedure.subject.Reference(no-basis-Patient!Patient) to Procedure.subject.Reference (Patient), This is a pragmatic decision in order to reduce the maintenance burden, and we already have a number of policies and guidelines to secure that clinical implementations follow our national profiling framework including the use of FHIR base profiles. We might revisit the decision when we have developed a broader set of no-basis-profiles, have established more solid goveranance structures and see possible tool support for functionality like the global-attribute. We will also evaluate downstream practical consequences over time of not referencing the full set of no-basis-profiles for validation etc.
Lloyd McKenzie (Oct 18 2021 at 15:04):
I'm not sure what you mean by "no-basis profiles"?
Øyvind Aassve (Oct 18 2021 at 15:23):
core profiles- general adaptions (identifiers, coding, extensions) to norwegian context independent of use case. However, very open without any must-support. Domain profiles profiles stricter for more specific use-cases - more information on page 25 in the last HL7 Europe newsletter: http://hl7.eu/download/eun-10-2021.pdf or from devdays here: https://www.youtube.com/watch?v=8pv-Zztibyg
Oliver Egger (Oct 18 2021 at 18:14):
in #switzerland we decided to add the profile references to the swiss base profiles so interested what the experiences in norway will be @Øyvind Aassve
Øyvind Aassve (Oct 18 2021 at 18:53):
Yep @Oliver Egger , we have also done this for a few years, and I know we are going a little out of sync with most similar inititatives around the world - therefore also this update :). However, we have insufficient maintenance resources in HL7 Norway for the moment as there are quite some pressurse on the development side. We are prioritzing development of base profiles based on actual adoption in projects, and for most new profiles we develop a number of exiting base profiles are outdataed because of not referencing the newly developed resources correctly (Reference no-basis). Out jugdment is now we will not lose too much by leaving them out for now. Will keep you updated.
Jose Costa Teixeira (Oct 18 2021 at 19:44):
I appreciate this. Indeed we have a lot of things pointing to be-profiles. Most of the priority is defined based on how often the data objects were relevant for the legacy standards, because we wanted to ensure that FHIR covers the same functional space.
Jose Costa Teixeira (Oct 18 2021 at 19:45):
We don't have domain-oriented profiles. Or I think perhaps we have, but that is what we call our be-profiles?
Jose Costa Teixeira (Oct 18 2021 at 19:46):
I recommended being liberal in this base profiling, just making sure that we meed the needs - not overconstraining.
Jose Costa Teixeira (Oct 18 2021 at 19:48):
side comment: We have a BePatient, and a NoPatient :smile:
Peter Jordan (Oct 18 2021 at 23:47):
Interesting discussion. In NZ, our approach to the Base IG has been to start with defining the extensions, identifiers and terminology - informed by existing implementations of FHIR and earlier standards, notably those used in National Systems. This is the base on which we will then create some national profiles but with a clear design goal not to, as @Jose Costa Teixeira says, 'over-constrain'. We are only creating a single, abstract artefact and will leave it up to the derived, 'concrete' IGs used by individual services and products to impose most strict constraints.
Øyvind Aassve (Oct 19 2021 at 11:03):
@Peter Jordan - I think we have a quite similar approach to base-profiling. Domain profiles are meant to excert more harmonization also in the stricter profiling - and we want to do this according to international implemenation guides if some exists and are relevant for the given domain. For example are we pointing to FHIR PHD IG and FHIR PoCG IG for personal devices and "high-acuity" hospital advices. And we want to be in charge of services that are being exposed so that we do not end up with american vendor following Argonaut and another vendor following IPS for example. Coming up now is national profiling on CarePlan and DiagnosticReport. Here we see the need for different national domain templates, depening on what kind of plan and what kind of DiagnosticReport.
Last updated: Apr 12 2022 at 19:14 UTC
