-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Coding display validation should consider all possible designations #3712
Comments
Performance question: will doing the designationValues.contains dramatically increase the time to validate large instances? |
1. Split `validateDisplay` into two flavors; now validateCode(CodeSystem, Coding, ValidationParameters) will use the passed CodeSystem to determine case sensitivity (instead of looking it up via the registry) 2. When the Coding.display doesn't match the lookup display, we now look for a match within the CodesSystem.concept.designation values before calling it invalid. 3. Added a designation to a couple sample code systems and added testValidateDisplay tests for both case-sensitive and case-insensitive behavior. Signed-off-by: Lee Surprenant <lmsurpre@merative.com>
* issue #3712 - check all CodeSystem concept designations 1. Split `validateDisplay` into two flavors; now validateCode(CodeSystem, Coding, ValidationParameters) will use the passed CodeSystem to determine case sensitivity (instead of looking it up via the registry) 2. When the Coding.display doesn't match the lookup display, we now look for a match within the CodesSystem.concept.designation values before calling it invalid. 3. Added a designation to a couple sample code systems and added testValidateDisplay tests for both case-sensitive and case-insensitive behavior. Signed-off-by: Lee Surprenant <lmsurpre@merative.com> * Apply suggestions from code review Signed-off-by: Lee Surprenant <lmsurpre@merative.com>
QA:
Before this change, the server would say thats invalid. Now that should succeed. |
The Patient resource type has a binding with CodeSystem for "Medical Record Number". {
"resourceType" : "Patient",
"active" : true,
"identifier": [
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v2-0203",
"code": "MR",
**"display": "Krankenaktennummer"**
}
],
"text": "Medical Record Number"
},
"system": "http://hospital.smarthealthit.org",
"value": "6db064db-2005-6b05-aeb2-b72a36df1a6f"
}
],
"name" : [ {
"family" : "Malan",
"given" : [ "David" ]
} ],
"gender" : "male"
} and the FHIRTermService.validateDisplay returned below outcome
Tried to create an instance of Patient with display value other than the CodeSystem display and designation values for "Medical Record Number" {
"resourceType" : "Patient",
"active" : true,
"identifier": [
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v2-0203",
"code": "MR",
**"display": "MR123"**
}
],
"text": "Medical Record Number"
},
"system": "http://hospital.smarthealthit.org",
"value": "6db064db-2005-6b05-aeb2-b72a36df1a6f"
}
],
"name" : [ {
"family" : "Malan5",
"given" : [ "David5" ]
} ],
"gender" : "male"
} and the FHIRTermService.validateDisplay returned below outcome
|
Prasanna found that even in the latter case ( The intention was for it to be informational only when we couldn't validate the code. |
I dug deeper into the above and I don't think its a regression. QUESTION: should we fail the transaction if a coding uses an invalid display value irregardless of the the binding strength?! It would be awful strict to reject something just because the display value is wrong when we would have accepted it if the code were missing altogether. Further, we only do this display value validation for concepts that exists in a bound valueset that has binding strength of preferred or higher. I think that could appear inconsistent/confusing to our users if we added the strict display code checking for just this one type of codes. But with that said, we do have an older / outstanding issue for adding Concept validation more generally (i.e. not just for codeable elements bound to a valueset). Therefor, I'll add the above commentary to that one (#1217) and close this one out. |
Is your feature request related to a problem? Please describe.
From https://hl7.org/fhir/datatypes.html#codesystem
However, CodeSystem.concept.display is
0..1
. Does it means you can use any of the "designations" for the Coding.display?Currently, our implementation only checks against CodeSystem.concept.display and not the corresponding designations.
This is in
FHIRTermService.validateDisplay
.Describe the solution you'd like
Instead of checking against just the CodeSystem.concept.display, check against any existing designation values as well.
Describe alternatives you've considered
Acceptance Criteria
AND a resource instance that has a Coding from that concept in this CodeSystem
WHEN you validate that instance
THEN it passes validation
Additional context
I opened https://jira.hl7.org/browse/FHIR-37603 to get some clarification from the spec authors.
The text was updated successfully, but these errors were encountered: