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
