Stream: IPS
Topic: incomplete summary
David Hay (Jan 29 2021 at 00:25):
I was asked by an implementer for the appropriate action to take when creating an IPS from a back end data store that has errors or omissions.
The scenario is a FHIR facade in front of an EHR which produces an IPS document on request by (using a FHIR operation) retrieving data from the back end system and assembling the summary from that. If there is an issue assembling the summary due to issues in the underlying datastore (say a medication refers to a non-existent drug or there is an invalid value for some element) then what should be in the IPS?
I would imagine that there should be an OperationOutcome in the document describing the error but should this also be a Composition.section? (ie 'Errors assembling this summary')
Should there be a note in the section.text / composition.text that indicates that the contents may be incomplete?
Should the status response to the operation be something other than 200 (eg 206 - partial content)?
And with regard to the affected resource (say with an un-mappable value) then should the resource be simply omitted or should the data that can be retrieved be included, but something on the resource (say a tag) to indicate that it is incomplete? And/or text in the narrative explaining the omission
Giorgio Cangioli (Jan 29 2021 at 07:10):
Hi @David Hay for required and recommended sections a set of concepts for conveying the non-availability of data (independently by the reason) have been included. See http://hl7.org/fhir/uv/ips/CodeSystem-absent-unknown-uv-ips.html
Giorgio Cangioli (Jan 29 2021 at 07:14):
in the case of medication the code is "no-medication-info". So, if for any reason you are not able to fill the medication section a single MedicationStatement valued with a medicationCodeableConcept = no-medication-info has to be provided.
Giorgio Cangioli (Jan 29 2021 at 07:16):
in the guide there are no indications on how to fill the section.text, but it reasonable that an appropriate text is provided to explain why the section is not correctly filled.
Giorgio Cangioli (Jan 29 2021 at 07:19):
the 'no-medication-info' should not be mixed-up with the 'no-known-medications' that is the one that should be used to say no medications to report for the purpose of the IPS.
Giorgio Cangioli (Jan 29 2021 at 07:19):
.. I don't know if this is what you were looking for...
Giorgio Cangioli (Jan 29 2021 at 07:20):
... glad to learn more from you :-)
René Spronk (Jan 29 2021 at 08:48):
IMHO: OperationOutcome: yes. Mention it in the text: Yes. Status code on the operation being 206: sounds good. All of these are best practices when it comes to error handling and traceability. There's also a meta.security tag which can be used to label a resource as being 'unreliable'.
In terms of patient safety: is it better to have at least some information (clearly labelled as being partial) or to have no data at all ? What would more likely lead to clinical errors ?
Giorgio Cangioli (Jan 29 2021 at 10:41):
René Spronk said:
In terms of patient safety: is it better to have at least some information (clearly labelled as being partial) or to have no data at all ? What would more likely lead to clinical errors ?
Maybe I misunderstood the initial question :-)
my answer was referring to the non-availability of information for a specific section.
A different situation is the case in which you may be aware that the list might be incomplete because - for example - one of the sources is not available. In this case you cannot use 'no-info' codes...
Giorgio Cangioli (Jan 29 2021 at 11:03):
The IPS is in any case a summary and does not pretend to document all the possible patient data (it is by design partial).
If and when to share a PS I believe it is a jurisdiction decision.
There are countries in which the PS shall be human curated and/or validated: in this case, it is a professional evaluation if an incomplete summary can be shared or not.
If it is automatically generated, I'd expect that rules are defined to determine the minimal content for disclosing the summary
Rob Hausam (Jan 29 2021 at 14:15):
I agree with Giorgio's and Rene's thoughts on this (and if I'm reading them correctly, I believe they should work together). As Giorgio said, I think the decision to share (and probably also what specific data is shared) will ultimately be jurisdiction-specific, but likely also there should be some general guidance that we can and should share in the IG. It seems that it's probably time for us to begin actively developing and compiling this for inclusion in future IG updates.
David Hay (Jan 29 2021 at 20:18):
Thanks guys - and in particular thanks @René Spronk for the security tag...
Lloyd McKenzie (Jan 29 2021 at 21:47):
Key thing is that the EHR must generate a 'valid' document - so if missing/corrupt/untranslatable elements would cause the element to be invalid, then you may have to omit containing elements until you get to one that's optional - and the error, whatever it is, would need to be reflected in something human-readable at that point.
I'm not sure that including an OperationOutcome is going to be terribly human-friendly. Most software that would spit out an OperationOutcome is going to be focused on conveying information to developers, less so to end-users. And the convention of a list of issues with pointers into varying portions of the document doesn't seem terribly human-friendly to me. I think it would be better to acknowledge errors/omissions/conversion issues as close to where they occur in a human-readable form than to have a summary in some separate section. (Particularly because portions of the document might be hived off and incorporated into the record and an OperationOutcome in a separate section almost certainly wouldn't come along for the ride.)
John Moehrke (Feb 01 2021 at 15:41):
I understand the technical constraint that @Lloyd McKenzie is mentioning, but it seems this would result in missing information that could be supplied simply because it points at something that can't be supplied. I don't know what the solution is, but it seems that this might happen in reality more than idealistic theory might imagine.
John Moehrke (Feb 01 2021 at 15:43):
This situation has also come up when that data are not missing, but have been blocked by policy (e.g. consent). I expect this to happen more often than a technical failure as was @David Hay example above. But it seems that we need to deal with reality too. right?
Jose Costa Teixeira (Feb 01 2021 at 18:14):
Not sure if related, but I had a question as I was looking at data sharing: When we exchange summary from country A to country B, can we tell
This is the data we have for you, please be aware that we don't have permission to share fields X, Y and Z, so the original may or may not have them, and you'll never know...
Giorgio Cangioli (Feb 01 2021 at 18:42):
Hi José,
referring to the only real case of cross-border exchange of Patient Summaries I'm aware of (the EU case), this is not a feature supported.
An EU-PS can be exchanged X-border if a set of agreed rules are fulfilled. Agreed rules include also the data that shall, should or may be included in the EU-PS for cross-border exchange.
Giorgio Cangioli (Feb 01 2021 at 18:45):
so, if, for example, a country of affiliation is not allowed to exchange medication data cross-border that simply means that that country will not be entitled to play the role of PS provider.
Giorgio Cangioli (Feb 01 2021 at 18:50):
in some countries, moreover, for specific kinds of information, you are not allowed to give evidence of the fact that these data have been masked... you just omit them...
Lloyd McKenzie (Feb 01 2021 at 18:51):
Right - but you can make a generic statement about certain information "might have been masked" - if you make the same statement for everyone
Jose Costa Teixeira (Feb 01 2021 at 19:02):
Ok. I wanted to bring an example of a cross-border exchange (Summary, or some other "document") - and the idea is to say "these are the masking rules that apply generally to this kind of record.
John Moehrke (Feb 01 2021 at 21:08):
that have-been applied? or need to be applied by the recipient?
John Moehrke (Feb 01 2021 at 21:12):
to indicate that data has been masked, use the MASKED code - These are from the valueset for SecurityIntegrityObservationValue and are an indication of possibly degraded quality due to the given reason -- https://terminology.hl7.org/1.0.0/ValueSet-v3-SecurityIntegrityObservationValue.html
John Moehrke (Feb 01 2021 at 21:14):
to indicate that a masking is needed you would use MASK code - These are from the valueset ObligationPolicy and are indications of an obligation the recipient is under. https://terminology.hl7.org/1.0.0/ValueSet-v3-ObligationPolicy.html
John Moehrke (Feb 01 2021 at 21:14):
These are codes... so they are not specific algorithms. Although one could imagine a more specific code that calls out a specific algorithm.
John Moehrke (Feb 01 2021 at 21:16):
If this algorithm need is strong enough we can add it to the justifications for the Permission resource to model. One could imagine that a Permission could represent a specific masking algorithm that the recipient is obligated to execute. I don't think that use-case has been well established, but it is logical for Permission scope.
John Moehrke (Feb 01 2021 at 21:19):
The use of MASKED code would be logical on the data Resource that has been degraded. This is very much similar to the instructions under FHIR "Summary" to use SUBSETTED code to indicate the data has been reduced to just the summary elements.
John Moehrke (Feb 01 2021 at 21:24):
The location of the codes for Obligations is not as obvious. This is where I prefer to put these obligations on the Bundle, as they are instructions associated with the interaction that caused the Bundle to exist, thus I see them existing on Bundle.meta.security. To put obligation codes on the data Resources does not seem right, as the data has not yet been MASKED or that would be the code of interest. However there is discussions that this plan to put obligations on the Bundle seems close to the dreaded context-conduction, which is forbidden in FHIR. I agree with the principle, but disagree that this is about context-conduction. It is a statement of "meta" about the "Bundle", therefore is Bundle.meta.security...
Jose Costa Teixeira (Feb 01 2021 at 22:02):
I was thinking of the Permission that comes along with the resource, saying "these are the constraints the resource went through and that the resource is expected to follow whenever used"
Peter Jordan (Feb 04 2021 at 02:10):
BTW: The FHIR Validator reports an "Unknown Code System" error for http://hl7.org/fhir/uv/ips/CodeSystem/absent-unknown-uv-ips
Rob Hausam (Feb 04 2021 at 02:25):
I didn't get that error with the IG Publisher when I built IPS this morning (and I'm sure I've never seen it for absent-unknown-uv-ips). Maybe the validator is behaving differently? We should look at an example.
Peter Jordan (Feb 04 2021 at 03:53):
I only get that error for the AllergyIntolerance Resource when used to populate the mandatory code element where there is no information (and the slicing in the IPS Profile definitely allows the use of that Code System in that element).
Using concepts from that Code System in Condition.code, MedicationStatement.Medication and Immunization.vaccineCode, on the entries created where there is no available information, doesn't upset the Validator.
Rob Hausam (Feb 04 2021 at 15:04):
Yeah, that seems odd. It still might be good to look at your example that's giving the error.
Last updated: Apr 12 2022 at 19:14 UTC
