Stream: fhircast-github
Topic: fhircast-docs / Issue #289 Proposal for DiagnosticReport ...
Github Notifications (FHIRcast) (Sep 15 2019 at 14:34):
gkustas opened Issue #289:
When reporting applications integrate with PACS and/or RIS applications, the radiologists workflow is centered around the Radiologist's final deliverable: the diagnostic report. While the imaging study (exam) is an integral resource, the report encapsulates one or more of these studies. Also, the diagnostic report contains certain attributes (such as report status), that are useful to the PACS/RIS applications and don't exist in the imaging study. Structured data, usually in the form of an Observation resource can also be encapsulated in the report.
I propose we consider adding DiagnosticReport-Open, DiagnosticReport-Update, and DiagnosticReport-Close events. Including [immature] samples below:
Example 1. new report requested by PACS/RIS, including priors.
```json
{
"timestamp": "2019-09-10T14:58:45.988Z",
"id": "0d4c9998",
"event": {
"hub.topic": "DrXRay",
"hub.event": "DiagnosticReport-open",
"context": [
{
"key": "Report",
"resource": {
"resourceType": "DiagnosticReport",
"identifier": "40012366",
"status": "unknown",
"code": "18748-4",
"imagingStudy": [
{
"reference": "ImagingStudy/342123458"
},
{
"reference": "ImagingStudy/1462123458"
}
]
}
},
{
"key": "PriorStudy",
"resource": {
"resourceType": "ImagingStudy",
"description": "CHEST XRAY",
"started": "2010-01-30T23:00:00.000Z",
"identifier": [
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v2-0203",
"code": "ACSN"
}
],
"value": "342123458"
}
}
]
}
},
{
"key": "Study",
"resource": {
"resourceType": "ImagingStudy",
"description": "CHEST XRAY",
"started": "2019-08-30T23:00:00.000Z",
"identifier": [
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v2-0203",
"code": "ACSN"
}
],
"value": "1462123458"
}
}
]
}
}
]
}
}Example 2. existing report signed and closed in reporting application ```json { "timestamp": "2019-09-10T14:58:45.988Z", "id": "0d4c9998", "event": { "hub.topic": "DrXRay", "hub.event": "DiagnosticReport-close", "context": [ { "key": "Report", "resource": { "resourceType": "DiagnosticReport", "identifier": "40012366", "status": "final", "issued" : "2019-09-13T14:58:45", "code": "18748-4", "ImagingStudy": [ { "reference": "ImagingStudy/alskdjfhe8lasd" } ] } }, { "key": "Study", "resource": { "resourceType": "ImagingStudy", "description": "CHEST XRAY", "started": "2019-08-30T23:00:00.000Z", "id" : "alskdjfhe8lasd", "identifier": [ { "type": { "coding": [ { "system": "http://terminology.hl7.org/CodeSystem/v2-0203", "code": "ACSN" } ], "value": "1462123458" } } ] } } ] } }
Github Notifications (FHIRcast) (Sep 16 2019 at 17:43):
wayfarer3130 commented on Issue #289:
There isn't any need to include the Study key, as that is implicit in the imaging reference in the diagnostic report.
Github Notifications (FHIRcast) (Sep 16 2019 at 17:50):
wayfarer3130 commented on Issue #289:
The Prior key should be Priors and should be a Bundle containing links or inline values. That way we can include more than one prior.
I'd also like to suggest that this be called "relevant" rather than "prior" as it actually is a reference to relevant documents, and not JUST studies. For example, the "relevant" list might include:
Condition - "Brain Cancer"
ServiceRequest - CT of the brain requested due to Observation
Observation - patient is experiencing numbness in legs
ImagingStudy - images from last CT showing tentative remission
ImagingStudy - images from initial CT show initial cancer diagnosis
Note these would all be short resource references rather than complete objects. The receiving system is expected to be able to look them up.
Github Notifications (FHIRcast) (Sep 29 2019 at 12:20):
gkustas commented on Issue #289:
@wayfarer3130, I have made updates to this proposal which I will post shortly. I'm also collaborating with @EricOnFHIR, working on a similar proposal issue #291.
We are struggling with how to include relevant objects into the context, since there is not elegant way already included in the FHIR spec. Right now we're thinking that including the ImagingStudy encounter - with start and end times - will be enough for the subscriber to know if the ImagingStudy is current or relevant. Assuming relevant studies have already ended of course.
Github Notifications (FHIRcast) (Nov 25 2019 at 10:47):
m-arpad commented on Issue #289:
Some additional questions:
- Is the Study a "REQUIRED" or "OPTIONAL" key in the Request Context Change's 'context' array? Can you always provide the ImagingStudy resources from a Reporting application? (If not, it is hard for the hub to identify the "full context", including Patient, ImagingStudy and DiagnosticReport. The hub would need this information for content sharing, see #291 in order to decide which _context_ the _content_ belongs to).
- (Minor) I guess the 'identifier' of DiagnosticReport in Example 1 is actually 'id', right?
- Why is the Patient missing from the context array (it is required for other '-Open' events)? More generally: should we always require the full graph of context objects to avoid ambiguity (in this example we would need Patient, ImagingStudy and DiagnosticReport) or can we assume some hierarchy already (in this example we would assume that the ImagingStudy is linked to a Patient already known by all applications taking part in the synchronization, hence the Patient information might be considered redundant)?
Last updated: Apr 12 2022 at 19:14 UTC
