Stream: smart
Topic: US-Core profiles for validation
Florian Briand (Feb 12 2020 at 15:58):
If I understand well the "core" concepts for SMART on FHIR, the data model is based on us-core profiles.
Nevertheless, when I try to use https://r3.smarthealthit.org/Patient/$validate (or r4) with
"meta": {
"profile": ["http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"]
},
I receive "StructureDefinition reference \"http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient\" could not be resolved".
And indeed, searching in /StructureDefinition resources, I was not able to find any us-core StructureDefinition
Is it normal ? Is there something I don't understand ?
Lloyd McKenzie (Feb 12 2020 at 16:22):
What server were you searching on? You can't necessarily expect most servers to have awareness of the US Core profiles - even if they support SMART on FHIR
Florian Briand (Feb 12 2020 at 16:26):
It's https://r3.smarthealthit.org, the "SMART on FHIR" official test server, so ... I was expecting them to be aware of the us-core profiles ;)
Lloyd McKenzie (Feb 12 2020 at 16:30):
Not necessarily something you can expect. The data might be expected to comply with the profiles - that doesn't mean the servers will have awareness of the profiles for validation purposes. It may be they're not hosted for exactly that reason. @Josh Mandel, thoughts?
Josh Mandel (Feb 12 2020 at 17:55):
The server as such is a generic FHIR server -- it can be used to store data that meet (or don't meet!) US Core profiles. When it comes to sample data, we try to generally align with these profiles (and most of the pre-loaded sample data just comes from Synthea at this stage).
Florian Briand (Feb 13 2020 at 07:32):
Do you think I should make a PR on the Github repository, to add us-core profiles to pre-loaded sample data ?
Not to make them mandatory, as I understand this is not the goal, but just to "have them available" :)
Jason Walonoski (Feb 13 2020 at 18:15):
BTW, Synthea can generate US Core data (with the profiles declared in meta), using the --exporter.fhir.use_us_core_ig=true command line switch.
Josh Mandel (Feb 13 2020 at 19:01):
Wait, are you talking about adding profile tags @Florian Briand , or about actually providing different data?
Jason Walonoski (Feb 13 2020 at 19:10):
I don't know exactly what he is talking about, but to be clear, when using that US Core switch synthea generates additional us core data (with some extra fields filled out and with some additional resources), in addition to declaring profile conformance in meta.
Florian Briand (Feb 13 2020 at 19:30):
The idea is to be able to use $validate?profile=...us-core-... operation to check a resource against the us-core profiles.
It's not to "always" do this validation, but allow people to do it.
To do so, we have to add the appropriates StructureDefinition on the server, the ones registering the us-core profiles, to made them available with the $validate operation.
But in practice, maybe the synthea's param add automatically the profiles also, so thank you for the tip :)
Josh Mandel (Feb 13 2020 at 19:41):
@Florian Briand I'm unclear on this point: if you're passing in profile= as an argument to the $validate operation, then it shouldn't be necessary for the data themselves to be tagged with anything specific in meta.profile. In other words, the validator shouldn't care about those tags; it's focused on content.
Florian Briand (Feb 13 2020 at 19:53):
Yes, there is no need to tag the data
Florian Briand (Feb 13 2020 at 19:55):
But to use validate, the profile have to exists, as a StructureDef on the server. The server seems not able to "fetch" the Profile using the provided URL
Josh Mandel (Feb 14 2020 at 22:51):
Wait, you're saying that every data server would need to store definnitional artifacts in order for a 3rd party server to validate? That doesn't sound right (or realistic).
Josh Mandel (Feb 14 2020 at 22:52):
The more likely scenario is: EHR server hosts data from its own internal database, using profiled FHIR. If a client wants to validate those data, the client is responsible for gathering up all the definitional artifacts required to perform validation (e.g., the client would obtain a validator and the US Core structure definitions).
Josh Mandel (Feb 14 2020 at 22:52):
In this context, the SMART reference stack is playing the role of an EHR (and nothing extra).
Grahame Grieve (Feb 16 2020 at 09:06):
the way we've defined it, a server that hosts the $validate operation has to host / locate the profiles value sets etc. And if the server wants to validate anyway (which it can ... and sometimes should), and it wants to validate against the profiles, then it also needs to locate them for itself
Grahame Grieve (Feb 16 2020 at 09:06):
a typical data server doesn't do that - it doesn't provide a $validate operation, and it validates based on it's internal logic, which mostly wouldn't depend on profiles (though it could)
Josh Mandel (Feb 19 2020 at 23:53):
To finalize this point then: hosting the $validate operation is not something that a SMART on FHIR server is expected to do.
Florian Briand (Feb 25 2020 at 17:48):
A classic "SMART on FHIR" server, yes ; but the ones used for demo/testing/... like https://r4.smarthealthit.org/metadata ? It could be a good idea, no ? ;)
Because everybody don't have a custom server in local, and it's quite painful to only have Grahame's ones to develop ;)
Josh Mandel (Feb 25 2020 at 20:13):
I think sometimes it does a disservice to developers if the "reference" implementation is way out ahead of what real-world servers can do. It's a careful balance. On this specific issue, I'd say that data validation (as a service, on specific inputs) is not a SMART server concern, so clients that care about validation should be provisioning their own resources.
Last updated: Apr 12 2022 at 19:14 UTC
