Hi Grahame,

I thinkj that is reasonable approach for now.

I found this useful material which seems to point to curren thinking
as DICOM-SR being the intra-dpeartmental standard, with external
reporting via ? CDA expression of RSNA XML templates. I would have
thought that we should aim for an archetype design which supports some
sort of aoutmated creation of RSNA-based openEHR templates (or CDA),
but it looks as if the base pattern will change to get better
alignment with DICOM-SR.

See

http://wiki.ihe.net/index.php?title=Management_of_Radiology_Report_Templates_-_Detailed_Proposal

and from IHE Cardiology Technical Committee DICOM WG8 - Structured
Reporting: Teleconference to Renew Activity (10/27/2010 11am CT)

"Description of Proposal
The scope of this work item is to define an initial set of templates
for imaging-related clinical content in CDA documents.  Sources for
the clinical requirements for these templates include the outcome of
the RSNA Reporting Initiative (~70 clinical templates), the ACC Key
Data Elements for Cardiac Imaging (supporting five different
modalities), and existing DICOM SR templates.
.....
The work will be undertaken by WG-08 (SR), in collaboration with
appropriate clinical representatives (e.g., the members of the RSNA
Reporting Initiative, the IHE Radiology and Patient Care Coordination
domains, and others).  Draft material will be provided to WG-20 / IIWG
for evaluation relative to conformance with the CDA standard and
consistency with other CDA templates, and for soliciting public
comment from interested parties in the HL7 community.  In particular,
this would be an appropriate agenda item for the standing joint
meeting of WG-20 / IIWG with the HL7 Structured Documents Work Group.

Nothing in this proposal is intended to detract from the use of DICOM
SR for exchange of structured information within the imaging
environment.  For example, SR is the preferred mechanism for detailed
imaging-based measurements and findings produced by imaging department
personnel or equipment (CAD), and intended to be used within the
department, or for consultation with imaging specialists at other
institutions, or for use by other imaging-intensive departments (e.g.,
surgery or radiation therapy).  CDA is complementary to this use, and
is better suited to communicate mostly professional diagnosis
information with other clinical information, which includes simple
image references and selected measurements extracted from the DICOM
SR.

http://groups.google.com/group/ihe-cardio-tech/browse_thread/thread/1b358f7f16fd3c5f
http://groups.google.com/group/ihe-cardio-tech/attach/a2adafe9459cd9ea/WG-08_CDA_Report_Templates-04.doc?part=4

Cheers,

Ian

Dr Ian McNicoll
office +44 (0)1536 414994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com

Clinical analyst,?Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care ?www.phcsg.org




On 19 January 2011 00:49, Grahame Grieve <grahame at kestral.com.au> wrote:
> Thanks Ian
>
> Here's what I recommend then:
> * we remove the existing model for structured details
> ?from the imaging exam archetype, and replace it
> ?with a todo. This will allow the current time critical
> ?processes to go ahead
>
> * I will review the SR model, the rsna standard headings,
> ?and other IHE and HL7 work, and then propose a model
> ?that is as simple and clear as possible while trying to
> ?meet as many explicit and implicit requirements as we can
> ?without making it unmanagable
>
> Is anyone unhappy with that?
>
> Grahame
>
>
> On Wed, Jan 19, 2011 at 11:36 AM, Ian McNicoll
> <Ian.McNicoll at oceaninformatics.com> wrote:
>> Hi,
>>
>> It's late here and my brain is fried so a brief reply for now.
>>
>> The DICOM SR material is very interesting, thanks for the reference.
>> Is it actually used or being developed for any RIS implementations?
>>
>> I based the broad structuring of the existing archetype on definitions
>> from RSNA found via
>>
>> http://reportingwiki.rsna.org/index.php?title=Standard_Radiology_Report_Headings
>>
>> This takes you eventually to a set of XML based radiology reporting
>> templates which at first sight felt more congruent with the archetype
>> than the DICOM SR approach but we definitely need to think a little
>> more about this.
>>
>> We need to be careful not to overstructure the base archetype but
>> allow room for expansion. It also seemed to me that Findings were
>> often arranged by structure or feature, rather than anatomical
>> location per se. e.g. The Chest x-ray report talks about findings of
>> Bones which includes ribs and spinal features.
>>
>> Again definitely worth further discussion and expert input though this
>> may not be available to us in the NEHTA timesscale
>>
>> Ian
>>
>> Dr Ian McNicoll
>> office +44 (0)1536 414994
>> fax +44 (0)1536 516317
>> mobile +44 (0)775 209 7859
>> skype ianmcnicoll
>> ian.mcnicoll at oceaninformatics.com
>>
>> Clinical analyst,?Ocean Informatics, UK
>> openEHR Clinical Knowledge Editor www.openehr.org/knowledge
>> Honorary Senior Research Associate, CHIME, UCL
>> BCS Primary Health Care ?www.phcsg.org
>>
>>
>>
>>
>> On 18 January 2011 23:02, Grahame Grieve <grahame at kestral.com.au> wrote:
>>> We did briefly talk about whether a DICOM SR report should be allowed as a 
>>> final
>>> report format to an EHR system. I don't think that it should be - that
>>> it's not suitable
>>> for this use. It's more for internal use in the PACS/RIS environment.
>>> Do you disagree?
>>>
>>> I guess the SR format speaks to the structured details part - we
>>> should at least
>>> align with it's capabilities. Sigh... I'll get around to reviewing them
>>>
>>> Grahame
>>>
>>>
>>> On Wed, Jan 19, 2011 at 9:43 AM, Graham Denyer <Graham.Denyer at 
>>> aad.gov.au> wrote:
>>>> Hi Heather et al
>>>>
>>>> You may well have already done so, but if not you should check out the 
>>>> structured reporting extension to the DICOM standard:
>>>>
>>>> ftp://medical.nema.org/medical/dicom/2008
>>>> -Part 3: SR SOP Classes (Section A.35), SR Modules (Section C.17)
>>>> -Part 16: Templates (Annex A)
>>>>
>>>> There is a very nice overview here:
>>>> http://www.pixelmed.com/srbook.html
>>>>
>>>> Graham
>>>>
>>>> _________________
>>>> Dr Graham Denyer FACRRM
>>>> Medical Officer
>>>> Polar Medicine Unit
>>>> Australian Antarctic Division
>>>> 203 Channel Highway
>>>> Kingston TAS 7050
>>>> Ph. +61 3 6232 3303
>>>> Mob. +61 419 123 038
>>>>
>>>>
>>>>
>>>>
>>>> From: openehr-clinical-bounces at openehr.org 
>>>> [mailto:openehr-clinical-bounces at openehr.org] On Behalf Of Heather 
>>>> Leslie
>>>> Sent: Tuesday, 18 January 2011 4:49 PM
>>>> To: For openEHR clinical discussions
>>>> Cc: Grahame Grieve
>>>> Subject: Re: Imaging Exam Archetype [SEC=Unclassified]
>>>>
>>>> FYI - I've attached the latest working draft of the archetype following 
>>>> today's discussions...
>>>>
>>>> Cheers
>>>>
>>>> Heather
>>>>
>>>> On 18/01/2011 3:48 PM, Grahame Grieve wrote:
>>>> hi Ian (and others)
>>>>
>>>> I spent some time today working on the imaging exam
>>>> archetype with Heather. We had some questions about
>>>> the Finding Details section, and Heather thought that
>>>> you are responsible for this part. And that part certainly
>>>> leaves me confused.
>>>>
>>>> There is a part called Detailed findings. In it, there is
>>>>
>>>> Finding name: Text
>>>> ?The name of the finding e.g Chest, heart or bones for a Chest x-ray.
>>>> Finding: Text
>>>> ?Brief description, often coded, of an individual finding from an
>>>> imaging procedure e.g. '2cm node in left upper lobe'.
>>>> Finding description: Text
>>>> ?A narrative, detailed description of each individual finding
>>>>
>>>> (note for other readers, this version of the archetype is
>>>> in preparation, and isn't posted to the CKM)
>>>>
>>>> I don't know what the intent is here. Howe do you differentiate
>>>> between these, and know
>>>> how to use them consistently?
>>>>
>>>> In fact, I wasn't exactly sure what "detailed findings" is exactly
>>>> meant to be - the
>>>> term isn't really defined. I assumed it was for some structured
>>>> representation of
>>>> the contents of the narrative, presumably to support some kind of synoptic
>>>> reporting? I'd add at least a Finding Value : ANY so that proper synoptic
>>>> reports would be possible.
>>>>
>>>> Heather and I thought that some examples might help have a productive
>>>> discussion.
>>>> This is some of the things I thought might be useful to say in a coded way
>>>> using snomed + values
>>>>
>>>> LMP: [value in months]
>>>> size of (uterus, placenta, foetus): [value in mm]
>>>> [Snomed Concept 84138006: Collapse of vertebra]
>>>> 246120007: Nodule size = [20mm]
>>>> 422005008: Ferucarbotran (product)
>>>>
>>>> That'll probably do to start us off. If no one claims reponsibility or
>>>> defends this
>>>> model, I'll suggest that we have just code | value following the classic 
>>>> HL7
>>>> model. It's certainly got it's problems, but at least they are well 
>>>> understood,
>>>> and the openEHR model would match the HL7 v2/v3 models of the same
>>>>
>>>> Grahame
>>>>
>>>> p.s. I tried to code exactly "2cm node in left upper lobe", but snomed
>>>> isn't vague
>>>> ?in those ways
>>>> _______________________________________________
>>>> openEHR-clinical mailing list
>>>> openEHR-clinical at openehr.org
>>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
>>>>
>>>>
>>>> --
>>>> Dr Heather Leslie
>>>> MBBS FRACGP FACHI
>>>> Director of Clinical Modelling
>>>> Ocean Informatics
>>>> Phone (Aust) +61 (0)418 966 670
>>>> Skype - heatherleslie
>>>> Twitter - @omowizard
>>>> ___________________________________________________________________________
>>>>
>>>> ? ?Australian Antarctic Division - Commonwealth of Australia
>>>> IMPORTANT: This transmission is intended for the addressee only. If you 
>>>> are not the
>>>> intended recipient, you are notified that use or dissemination of this 
>>>> communication is
>>>> strictly prohibited by Commonwealth law. If you have received this 
>>>> transmission in error,
>>>> please notify the sender immediately by e-mail or by telephoning +61 3 
>>>> 6232 3209 and
>>>> DELETE the message.
>>>> ? ? ? ?Visit our web site at http://www.antarctica.gov.au/
>>>> ___________________________________________________________________________
>>>>
>>>> _______________________________________________
>>>> openEHR-clinical mailing list
>>>> openEHR-clinical at openehr.org
>>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
>>>>
>>>
>>>
>>>
>>> --
>>> -------------
>>> Grahame Grieve, Health Intersections Pty Ltd.
>>> grahame at healthintersections.com.au | 
>>> http://www.healthintersections.com.au
>>>
>>> _______________________________________________
>>> openEHR-clinical mailing list
>>> openEHR-clinical at openehr.org
>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
>>>
>>
>> _______________________________________________
>> openEHR-clinical mailing list
>> openEHR-clinical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
>>
>
>
>
> --
> -------------
> Grahame Grieve, Health Intersections Pty Ltd.
> grahame at healthintersections.com.au | http://www.healthintersections.com.au
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
>


Reply via email to