Stream: argonaut
Topic: deleted resource expectation
John Moehrke (Jul 17 2020 at 13:43):
I have reviewed the US-Core IG on the topic of deleted resources and resources marked as not active. I am still confused as to what is happening in the real world. From the US-Core IG it seems that a server must throw an error if a query is missing a status parameter. This seems logical, as it drives good clients to be aware that the status element is important. But I am also not clear if this is universal, or if there are systems that are interpreting a missing status parameter as an implied status=active?
John Moehrke (Jul 17 2020 at 14:02):
also, what does a blank resource mean in the section Representing Deleted Information
for patient viewing systems the content of resource SHOULD be removed. In other words a blank resource.
must a server return an blank Resource that has the status marked entered in error? What exactly is blank?
or is this a client requirement that if it sees an entry in a bundle that is marked as entered in error it MUST show a blank line? Is this an ink line, void, ???
Michele Mottini (Jul 17 2020 at 14:45):
seems that a server must throw an error if a query is missing a status parameter.
mhh, don't think so. Query with just patient are fine (and the most common ones I guess)
John Moehrke (Jul 17 2020 at 14:48):
http://hl7.org/fhir/us/core/general-guidance.html#search-for-servers-requiring-status
Michele Mottini (Jul 17 2020 at 14:51):
Yes, it say that a server _might_ require a status parameter, not that it has to - and all server I worked so far do not
John Moehrke (Jul 17 2020 at 14:52):
so they only return active results (like one might expect)? or they return ALL results (like FHIR core defines)? That is exactly the question I was asking.
Michele Mottini (Jul 17 2020 at 14:53):
I sure hope they return all results - that would be against FHIR specs not to
John Moehrke (Jul 17 2020 at 15:03):
well, that is the question... Because I have seen a set of FHIR apps that are not including status parameter, and showing entered-in-error the same way they show active... so I figure some server is not behaving, and filtering implicitly. (Was this different in the DSTU2 days?)
Eric Haas (Jul 17 2020 at 15:06):
a blank resource means a valid resource that only exposed the bare minimum elements e.g. the status or masks the content.
e.g.
resourceType: AllergyIntolerance
clinicalStatus:
coding:
- system: 'http://terminology.hl7.org/CodeSystem/allergyintolerance-clinical'
code: entered-in-error
John Moehrke (Jul 17 2020 at 15:07):
Eric Haas said:
a blank resource means a valid resource that only exposed the bare minimum elements e.g. the status or masks the content.
e.g.
resourceType: AllergyIntolerance
clinicalStatus:
coding:- system: 'http://terminology.hl7.org/CodeSystem/allergyintolerance-clinical' code: entered-in-error
so is this a server responsibility to return these blanks? or is it a client requirement to have a UI blank?
Eric Haas (Jul 17 2020 at 15:48):
I think the servers will be in CYA mode no matter what the spec says
John Moehrke (Jul 17 2020 at 16:22):
so, what there would need to be a blank resource that is compliant with US-Core... and I don't think that can exist... right? What is a compliant blank Observation?
Eric Haas (Jul 17 2020 at 16:28):
yes without a bunch of masking extensions would be invalid for anything with a min=1. but see my CYA post above
Eric Haas (Jul 17 2020 at 16:28):
make a tracker
John Moehrke (Jul 17 2020 at 16:28):
right, so it would be as blank as FHIR Core, but not likely us-core compliant
John Moehrke (Jul 17 2020 at 16:30):
yea, I think us-core needs to be more clear that the text about blank resource is informative, and not a normative statement. and that it is a possibility for a server to respond this way. is that what you are thinking the CR would say?
John Moehrke (Jul 17 2020 at 17:00):
https://jira.hl7.org/browse/FHIR-28091
Jenni Syed (Jul 17 2020 at 17:51):
@John Moehrke the point of adding that status clarification was to allow servers to be explicit in what they required and be valid per spec. IE: if they had some internal requirement that you have to explicitly ask for in error, then they should fail if you pass in no status since the "default" doesn't conform to spec
Last updated: Apr 12 2022 at 19:14 UTC
