Stream: inferno
Topic: DocumentReference failed validator from missing contentType
Nathan Loyer (Apr 06 2022 at 17:32):
Hey, continuing a conversation that was started here:
https://github.com/onc-healthit/onc-certification-g10-test-kit/issues/67
So here's another failure we're having when running the g10 tests. We have a DocumentReference being returned for a patient that has a status of entered-in-error, and thus we have no attachment that we want to return for the resource. Because of this, we are setting the data-absent-reason extensions on DocumentReference.content.attachment, DocumentReference.content.attachment.contentType, and DocumentReference.content.attachment.data. The FHIR validator doesn't seem to like this, and it returns an error because we have no code in the contentType field. So is our implementation wrong to return data like this? Or is this something the validator needs to be updated to handle?
Here's an example of the data that triggers this:
{
"custodian": {
"reference": "Organization/234124"
},
"resourceType": "DocumentReference",
"date": "2017-01-01T00:00:00.000Z",
"status": "entered-in-error",
"subject": {
"reference": "Patient/978124"
},
"content": [
{
"attachment": {
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}
],
"_data": {
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}
]
},
"_contentType": {
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}
]
}
},
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}
]
}
],
"author": [
{
"reference": "Organization/1237648"
}
],
"meta": {
"security": [
{
"system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
"code": "NOPAT",
"display": "no disclosure to patient, family or caregivers without attending provider's authorization"
}
]
},
"identifier": [
{
"system": "https://fhir.athena.io/sid/ah-documentreference",
"value": "12489"
}
],
"context": {
"encounter": [
{
"identifier": {
"system": "https://fhir.athena.io/sid/ah-encounter",
"value": "1039478"
},
"reference": "Encounter/1239487"
}
],
"period": {
"end": "2021-01-01",
"start": "2021-01-01"
}
},
"category": [
{
"coding": [
{
"system": "http://hl7.org/fhir/us/core/CodeSystem/us-core-documentreference-category",
"code": "clinical-note",
"display": "Clinical Note"
}
]
}
],
"id": "01927834",
"type": {
"coding": [
{
"system": "http://loinc.org",
"code": "75425-9",
"display": "Cardiology Diagnostic Study Note"
}
]
}
}
and the error:
{
"resourceType": "OperationOutcome",
"text": {
"status": "extensions",
"div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><table class=\"grid\"><tr><td><b>Severity</b></td><td><b>Location</b></td><td><b>Code</b></td><td><b>Details</b></td><td><b>Diagnostics</b></td><td><b>Source</b></td></tr><tr><td>ERROR</td><td/><td>Invalid Code</td><td>No code provided, and a code is required from the value set</td><td/><td>No display for Extension</td></tr></table></div>"
},
"issue": [
{
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-line",
"valueInteger": 29
},
{
"url": "http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-col",
"valueInteger": 27
},
{
"url": "http://hl7.org/fhir/StructureDefinition/operationoutcome-issue-source",
"valueCode": "InstanceValidator"
}
],
"severity": "error",
"code": "code-invalid",
"details": {
"text": "No code provided, and a code is required from the value set"
},
"expression": [
"DocumentReference.content[0].attachment.contentType"
]
}
]
}
Nathan Loyer (Apr 06 2022 at 17:32):
@Yunwei Wang
John Moehrke (Apr 06 2022 at 17:39):
interesting point. I would expect the profile is mostly targetting active DocumentReference, not entered-in-error.
Nathan Loyer (Apr 06 2022 at 17:43):
I believe in this case the data is soft-deleted in our servers, which we've decided to represent as entered-in-error and not return the data
Yunwei Wang (Apr 06 2022 at 17:44):
I run the resource with HL7 fhir-validator jar. According to the result, you have to provide content-type code. You cannot use DAR extension there.
Yunwei Wang (Apr 06 2022 at 17:45):
The tricky thing is that the content-type has a datatype of code.
John Moehrke (Apr 06 2022 at 17:47):
Seems there should be a different profile expectation for entered-in-error. Not unusual for an instance that was formerly published that was eventually found to be wrong, to be marked as entered-in-error to notify previous readers that the data they pulled should be not relied upon, and not unusual for this instance to have all former element values blanked... (vs delete, which is not very transparent).
Yunwei Wang (Apr 06 2022 at 17:51):
Oh, I got it. contentType has a "required" binding. It shows in the "Full View". So you must provide a value from the bound valueset.
Nathan Loyer (Apr 06 2022 at 17:51):
right, so what do we do when there isn't actually any content we want to share?
Nathan Loyer (Apr 06 2022 at 17:51):
Seems like we could choose to leave the resource as-is but set the contentType to something. I don't see any mime types that correspond to empty data or null data, but I found a stack overflow page suggesting example/example could be used for this purpose
Nathan Loyer (Apr 06 2022 at 17:52):
https://stackoverflow.com/a/56295737
Yunwei Wang (Apr 06 2022 at 17:54):
I run some test. These should work
"content": [
{
"attachment": {
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}
]
},
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}
]
}
],
John Moehrke (Apr 06 2022 at 17:54):
I think this is a failure of the specification, not the test tool. right?
Nathan Loyer (Apr 06 2022 at 17:55):
@Yunwei Wang that however fails the US Core tests
"text": "us-core-6: 'DocumentReference.content.attachment.url or DocumentReference.content.attachment.data or both SHALL be present.' Rule 'DocumentReference.content.attachment.url or DocumentReference.content.attachment.data or both SHALL be present.' Failed"
Nathan Loyer (Apr 06 2022 at 17:56):
aha!
"content": [
{
"attachment": {
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}
],
"_url": {
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}
]
}
},
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
"valueCode": "unknown"
}
]
}
],
Nathan Loyer (Apr 06 2022 at 17:56):
that passes everything
Yunwei Wang (Apr 06 2022 at 17:57):
:tada:
Nathan Loyer (Apr 06 2022 at 17:57):
so I think we can just switch to setting url to have the absent reason and remove content type and data
Nathan Loyer (Apr 06 2022 at 17:58):
John Moehrke said:
I think this is a failure of the specification, not the test tool. right?
I'm not sure... seems like we have the option to work around this by using url instead of data + contentType
Yunwei Wang (Apr 06 2022 at 18:00):
@Eric Haas Is this the correct way to express a DocuemntReference without attachment? It valid (according to validator) but looks strange.
John Moehrke (Apr 06 2022 at 18:05):
well, I took this discussion and decided that I will file an "improvement opportunity" for the parallel work using DocumentReference in IHE (aka MHD).
Nathan Loyer (Apr 06 2022 at 18:10):
my teammate pointed out contentType seems to still be required even if url is provided instead of data...
Yunwei Wang (Apr 06 2022 at 18:40):
Yes. you still need to provide contentType. My mistake. I didn't provide -profile parameter in my previous testings.
Yunwei Wang (Apr 06 2022 at 18:47):
@Nathan Loyer Your use case is similar to what discussed in this thread: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Period.20Datatype.20Invariant
Andrew Feeney (Apr 06 2022 at 18:48):
Is it correct for us-core-6 to be checked on an object that is indicated to be missing? That seems strange.
Yunwei Wang (Apr 06 2022 at 19:01):
I tried the latest validator_cli v5.6.40. It gives the same error.
Eric Haas (Apr 06 2022 at 19:47):
Entered in error is not the same as missing US Core latest guidance on entered in error data is here: http://build.fhir.org/ig/HL7/US-Core/general-guidance.html#representing-entered-in-error-and-deleted-information
and it states :
Note this typically will not be conformant with the US Core or FHIR StructureDefinitions.
John Moehrke (Apr 06 2022 at 19:48):
nice... but then the profile should not allow entered-in-error status... right?
Nathan Loyer (Apr 06 2022 at 20:24):
I guess it seems like you're suggesting if the status is entered-in-error then it is expected for the resource to not conform with the profile... but this data exists on a patient we intended to test with inferno for our certification, so... do we just not use this patient?
Nathan Loyer (Apr 06 2022 at 20:24):
er, patient. I'll edit that
John Moehrke (Apr 07 2022 at 11:45):
Yes, i am saying that when status is entered-in-error, it should not be tested against the profiles. Which Eric has found the text that indicates this.
John Moehrke (Apr 07 2022 at 11:46):
it is unfortunate that the profiles do allow for entered-in-error, as that implies that they shall be compliant. But together the profile and the note indicate to me that entered-in-error might be compliant, but might not... therefore, no use in validating it.
Nathan Loyer (Apr 07 2022 at 17:23):
Maybe inferno tests should be updated to turn fhir validator failures into warnings when the status is entered-in-error
Yunwei Wang (Apr 07 2022 at 18:44):
Inferno has to follow the US Core v3.1.1 which is required by g10 test procedure. You can
1) raise a JIRA ticket on US Core IG asking to 'patch' US Core 3.1.1 with the same guidance as Eric quoted
2) raise a feedback to ONC to clarify the test procedure on error data
Nathan Loyer (Apr 07 2022 at 20:20):
The us core 3.1.1 docs seem to say the same thing as the page Eric linked:
https://hl7.org/fhir/us/core/STU3.1.1/general-guidance.html#representing-entered-in-error-and-deleted-information
Nathan Loyer (Apr 07 2022 at 20:20):
I don't think any updates to the spec are needed
Nathan Loyer (Apr 07 2022 at 20:23):
It doesn't have that note
Note this typically will not be conformant with the US Core or FHIR StructureDefinitions.
but it does have
If the status is entered-in-error:
for patient viewing systems the content of resource SHOULD be removed. In other words a blank resource.
A provider facing system MAY be supplied with additional details that the patient viewing system would typically not have access to.
which seems to still be the spec saying that if the status is entered-in-error, then it wont be completely compliant with the profiles
Yunwei Wang (Apr 07 2022 at 22:16):
IMO, this is why we have DAR extension. I know the problem here is the BCP code. Other than that, DAR should be used.
Drew Torres (Apr 08 2022 at 15:04):
The intent of the spec and language was to always hide data that was potentially dangerous to show certain audiences. That is why we carved out the exceptions around entered-in-error. If a provider puts in data for the wrong patient and a patient facing application downloaded that data. The status was a way to cue that application to remove that resource. The intent was to only populate fields that were absolutely required to remain FHIR compliant and not to meet the requirements of the profile....
IMO DAR is getting used a bit too much. Why populate a bunch of fields with DAR unknown? It bloats the resource and articulates nothing more than what the status already did.
Nathan Loyer (Apr 08 2022 at 15:18):
I would agree there. We only add the DAR objects so our resources are compliant with the profiles.
Nathan Loyer (Apr 08 2022 at 15:20):
Nathan Loyer said:
aha!
"content": [ { "attachment": { "extension": [ { "url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason", "valueCode": "unknown" } ], "_url": { "extension": [ { "url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason", "valueCode": "unknown" } ] } }, "extension": [ { "url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason", "valueCode": "unknown" } ] } ],
So back to the issue at hand... I can't duplicate what I did the other day anymore... I think I might have accidentally scrolled up to much to a previous response or something. I don't have my cli logs for these runs anymore because I rebooted, and I can't replicate my success. So now we're back to the drawing board of what to do for this resource.
Nathan Loyer (Apr 08 2022 at 15:28):
options that I am considering...
- add a contentType setting to something even though there is no content, could use example/example or something
- just hard delete this record so the tests pass
- convince yall to update inferno to not fail when a resource with status of entered-in-error resource fails profile validation
My preference is the third item :)
Yunwei Wang said:
Inferno has to follow the US Core v3.1.1 which is required by g10 test procedure. You can
1) raise a JIRA ticket on US Core IG asking to 'patch' US Core 3.1.1 with the same guidance as Eric quoted
2) raise a feedback to ONC to clarify the test procedure on error data
Do you still think those items are necessary to change this? I feel like the current text of 3.1.1 says the same thing as what Eric quoted, albeit less explicitly.
John Moehrke (Apr 08 2022 at 15:34):
I think Eric gave the golden quote...
Nathan Loyer (Apr 08 2022 at 15:41):
Right, but that was in the us core 4.0.0 and above and not in 3.1.1
John Moehrke (Apr 08 2022 at 15:42):
it does set precedence. and there is no way to change 3.1.1... right?
Drew Torres (Apr 08 2022 at 15:43):
http://hl7.org/fhir/us/core/STU3.1.1/general-guidance.html#representing-deleted-information
If the status is entered-in-error:
for patient viewing systems the content of resource SHOULD be removed. In other words a blank resource.
Drew Torres (Apr 08 2022 at 15:44):
That language is in 3.1.1
Nathan Loyer (Apr 08 2022 at 15:44):
John Moehrke said:
it does set precedence. and there is no way to change 3.1.1... right?
I believe Yunwei's comments were specifying how we can get 3.1.1 updated to add this bit of clarity, but I'm trying to argue that the current text is sufficient to justify our interpretation.
Yunwei Wang (Apr 08 2022 at 16:03):
First, the narrative in v4.0 is much better than v3.1.1. That is why I mentioned the narrative in v3.1.1 should be 'patched'
I am concerned this could fundamentally change the FHIR validation. Should FHIR validator just ignore any resources with enter-in-error status?
We should be very careful here. If a server only provides "incomplete" (I don't know what the correct phrase is to describe this use case) resources with enter-in-error status, does that server conforms to US Core IG? (@Eric Haas )
Even this is the intention of US Core, (g)(10) certification has higher bar than US Core. According to the test procedure
The health IT developer demonstrates the ability of the Health IT Module to respond with data that meet the following conditions:
All data elements indicated with a cardinality of one or greater and / or “must support” are included;
ONC has the final word on this test procedure requirement.
Drew Torres (Apr 08 2022 at 16:10):
The correct course would be to log a JIRA to ONC for clarification on that language, but that language doesn't dictate or take into consideration of conditionality. That language is merely saying that the certified system must support every field that profile calls out. That language was probably included because of how everyone thinks of must support differently. It doesn't say that in the error example that every field must be populated that the profile calls out because the IG specifically calls out the entered-in-error example and allows for the exception.
Drew Torres (Apr 08 2022 at 16:11):
The question of entered-in-error for any resource... I would say yes because the language is included in a section of specification above specific profile artifacts and each profile should inherit that rule.
John Moehrke (Apr 08 2022 at 16:16):
what is the use in having entered-in-error count towards compliance at all? I definitely think it must not be forbidden, but successfully having resources with entered-in-error are simply a fact-of-life. Their existence should be agnostic to compliance.
Drew Torres (Apr 08 2022 at 16:18):
And to the other question if a server only support "incomplete" data... That has always stumped us. We never know what it means to be "fully" compliant. Because there is a capability statement that include all sorts of operations included in the IG. If the server support only 1 resource is that compliant? I think some people would say yes.
Certification calls out what must be tested and creates the context of compliance here. There isn't anything in certification that says what the IG has called out as being against the rules.
Drew Torres (Apr 08 2022 at 16:19):
John Moehrke said:
what is the use in having entered-in-error count towards compliance at all? I definitely think it must not be forbidden, but successfully having resources with entered-in-error are simply a fact-of-life. Their existence should be agnostic to compliance.
Exactly right. It is an unfortunate reality of humans entering data into the system. We cannot hold mistakes up to the same standard and valid data.
Nathan Loyer (Apr 08 2022 at 16:34):
Yunwei Wang said:
I am concerned this could fundamentally change the FHIR validation. Should FHIR validator just ignore any resources with enter-in-error status?
We should be very careful here. If a server only provides "incomplete" (I don't know what the correct phrase is to describe this use case) resources with enter-in-error status, does that server conforms to US Core IG? (Eric Haas )
I would say if a server only returns DocRef resources that are entered-in-error and have no data for anything required, then that would not be compliant, but if the server returns 20 DocRefs for the test patients, 19 of which are fully compliant with the spec, but one has entered-in-error status and no other data, then that should count as being compliant.
Nathan Loyer (Apr 08 2022 at 16:34):
Which that is what is happening for us with our current test runs.
Nathan Loyer (Apr 08 2022 at 16:37):
So it sounds like we need ONC to give us a judgement here, even if that amounts to them approving of our interpretation and giving yall the greenlight to make a corresponding update to the test code without changes to the us core spec.
I've never spoken directly with them, how do we initiate that? You mentioned a Jira board, which one would that be?
Eric Haas (Apr 08 2022 at 16:42):
This is an edge case where systems are not going to expose this information to their patients no matter the conformance implications.
Drew Torres (Apr 08 2022 at 16:46):
Right the question is whether on not we want a bunch of DARs... Which seem like a waste of resources.
Drew Torres (Apr 08 2022 at 16:48):
Not sure if this is the right place to log a clarifying question to ONC: https://oncprojectracking.healthit.gov/wiki/olp
Create issue: https://oncprojectracking.healthit.gov/support/login.jsp?os_destination=%2Fsecure%2FCreateIssue%21default.jspa
Search issue: https://oncprojectracking.healthit.gov/support/issues/?jql=
Drew Torres (Apr 08 2022 at 16:49):
I suspect they are going to defer to the spec here.
Yunwei Wang (Apr 08 2022 at 16:52):
That loops back to @John Moehrke 's question. If we say that enter-in-error is an exception from other status, why do we even have enter-in-error in US Core?
Drew Torres (Apr 08 2022 at 16:55):
Because it isn't a final say that all entered-in-error won't follow us-core... There may be instances where a provider app, or some other integration may be allowed to get all data and may be returned... I think there is some weird thing because it is a status you can't modify the values because it is required and dictated by the base spec. In reality what is probably a good middle ground is some mechanism for a server to communicate at a per resource level if it conforms to the profile for that resource.... Not sure it is really needed, but it is probably the best of both worlds.
Drew Torres (Apr 08 2022 at 16:56):
Removing entered-in-error from the value set creates another set of problems.
John Moehrke (Apr 08 2022 at 17:07):
just because an entered-in-error might be compliant, does not mean that concept needs to be inscope.
Yunwei Wang (Apr 08 2022 at 17:08):
This came out from an edge case that there is not unknown code for contentType. In general, is this a common process for an EHR to serve incomplete resource through FHIR API?
Drew Torres (Apr 08 2022 at 17:09):
What are you defining as incomplete?
Drew Torres (Apr 08 2022 at 17:09):
In any definition... the answer is yes.
Drew Torres (Apr 08 2022 at 17:09):
Because it potentially just as dangerous to "hide" resources to expose "incomplete" resources.
Yunwei Wang (Apr 08 2022 at 17:10):
I found a similar discussion already happened at
https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Period.20Datatype.20Invariant
and
https://chat.fhir.org/#narrow/stream/179175-argonaut/topic/US.20Core.3AExtensible.20and.20Required.20bindings.20for.20historical.20data
and a JIRA ticket
https://jira.hl7.org/browse/FHIR-25183
Yunwei Wang (Apr 08 2022 at 17:11):
After three years, we are still looking for an answer.
Drew Torres (Apr 08 2022 at 17:12):
LOL
Drew Torres (Apr 08 2022 at 17:12):
I was about to day the same thing...
Drew Torres (Apr 08 2022 at 17:14):
I mean interoperability is hard.... Especially with how people understand things differently, when we have 20+ years of data that don't meet today's standards, and when humans are still involved.. The intent of what we did in US-Core is create meaningful profiles that are usable. We tried to allow for "bad" data to be communicated without being too overbearing to implementers.... The fact that we have an EHR trying to stick DARs for a bunch a fields just to pass a test goes against what we intended.
Drew Torres (Apr 08 2022 at 17:17):
John Moehrke said:
just because an entered-in-error might be compliant, does not mean that concept needs to be inscope.
Fair enough. I think some of the things that would have to be figured out if we go down that route (BTW doesn't solve for current certification because SVAP wouldn't include it so the current tests/tools would need to abide by what the IG states currently):
1.) Are we allowed to change the required status binding? I thought not, but I may be making it up.
2.) How do we remove that one field?
3.) What happens when you have an entered-in-error in a bundle of "compliant" resources? Doesn't the consumer still have to code for this exception anyways?
John Moehrke (Apr 08 2022 at 17:18):
Postel's Law
Drew Torres (Apr 08 2022 at 17:20):
That is always best practice :-D
Keith Carlson (Apr 11 2022 at 13:09):
Nathan Loyer said:
So it sounds like we need ONC to give us a judgement here, even if that amounts to them approving of our interpretation and giving yall the greenlight to make a corresponding update to the test code without changes to the us core spec.
I've never spoken directly with them, how do we initiate that? You mentioned a Jira board, which one would that be?
ONC's official inquiry portal is located here: https://www.healthit.gov/feedback and please feel free to submit your questions to us
Nathan Loyer (Apr 12 2022 at 16:03):
So I was chatting with @Joe Paquette about this today... he pointed out something that I missed, which is that the caveats in the spec about returning empty/blank resources when the status is entered-in-error are specific to patient viewing systems, which I took to mean when the request has a token for a patient standalone launch. There is no claim in here saying that the data should be removed when the request is coming from provider facing systems or backend system/system calls, which I took to mean EHR launch tokens and 2-legged tokens respectively.
Note that when we are running this single patient API test suite, we are using the EHR launch tokens... so that is leading me to believe that we should be returning all of this data if we still have it in the database with the status of entered-in-error. When it's a patient user token making the request the data should be redacted, but all other use cases should return the data if it is available.
I haven't logged a ticket to the ONC Jira yet, we were working on how we wanted to write up the request when we discovered this caveat, which might make a ticket for this unnecessary...
Last updated: Apr 12 2022 at 19:14 UTC
