FHIR Chat · Inferno Validator - CareTeam.Status · inferno

Stream: inferno

Topic: Inferno Validator - CareTeam.Status


view this post on Zulip Nihar (Sep 23 2021 at 12:48):

Hello,

We were trying to validate the Care Team resource under the FHIR Validator and even though the CareTeam.status is missing in the json file, it didn't gave a Validation Error.

-- Resource Start--
{
"resourceType" : "CareTeam",
"id" : "05WXG875EVBKVAH01V5E",
"meta" : {
"profile" : [
"http://hl7.org/fhir/us/core/StructureDefinition/us-core-careteam"
]
},
"name" : "CareTeam",
"subject" : {
"reference" : "Patient/PD923892939X2",
"display" : "Jane Doe"
},
"participant" : [
{
"role" : [
{
"coding" : [
{
"system" : "http://snomed.info/sct",
"code" : "17561000",
"display" : "Cardiologist"
}
]
}
],
"member" : {
"reference" : "Practitioner/97654a5188",
"display" : "Ross Makoyer, MD"
}
}
]
}
-- Resource End --
image.png
Please suggest are we missing onto, any understanding related to the such data elements along with Validator. Please guide.

view this post on Zulip Stephen MacVicar (Sep 23 2021 at 13:03):

CareTeam.status has 0..1 cardinality, so it is not required.

view this post on Zulip Nihar (Sep 23 2021 at 13:59):

Hi @Stephen MacVicar : Thanks for the Update. CareTeam.Status is marked as the Must Support Element and if we read the Inferno Test Case USCCT-07, it suggest that it must have Status and as element is mentioned in the listing, inferno will check this element before passing that test case.
image.png

view this post on Zulip Stephen MacVicar (Sep 23 2021 at 14:11):

US Core Must Support Guidance: http://hl7.org/fhir/us/core/STU3.1.1/general-guidance.html#must-support
Not having CareTeam.status doesn't make a resource invalid. Every resource doesn't have to populate that field, but the server has to demonstrate that it can populate it in at least one resource.

view this post on Zulip Nihar (Sep 23 2021 at 15:08):

@Stephen MacVicar : I'm really sorry, for so many questions but I'm bit confused. The Link that you suggested doesn't have specificity that we as the responder can ignore the implementation of those MUST SUPPORT elements which are having the Cardinality as 0..1.Please Guide...We are under impression that all the Must Supported Elements needs to be supported as the response.

Also, requesting you to please elaborate what you are trying to explain by "Every resource doesn't have to populate that field, but the server has to demonstrate that it can populate it in at least one resource."?

view this post on Zulip Stephen MacVicar (Sep 23 2021 at 16:42):

They need to be supported. Systems have to be capable of populating them. That doesn't mean that every resource must contain them. In order for a system to demonstrate that it is capable of populating a must support field, inferno has to see that field in at least one resource, not in all resources.

view this post on Zulip Nihar (Sep 23 2021 at 17:06):

@Stephen MacVicar : Okay, from Inferno perspective we don't need to have Must Support elements supported for all the resources rather it is required in at least one resource...whereas from the US Core Compliance Perspective, we as the responder/server need to implement all the MUST Support elements under each resources. Is this the right understanding?

view this post on Zulip Stephen MacVicar (Sep 23 2021 at 17:12):

No, US Core does not say that every resource must contain every must support element: http://hl7.org/fhir/us/core/STU3.1.1/general-guidance.html#must-support

view this post on Zulip Yunwei Wang (Sep 23 2021 at 17:59):

"MustSupport" on a element means that a server/response must be able to demonstrate that it can populate this element. Inferno tests "MustSupport" by checking that in resources returned from the server, there is at least one resource having that element populated


Last updated: Apr 12 2022 at 19:14 UTC