Hi Peter, Using FEEDER_AUDIT was actually discussed as part of deciding how best to handle Placer and Filler Order numbers in lab tests etc . The problem we have is that we also need to add these identifiers to outgoing order /referral messages (and track those within the EHR), and FEEDER_AUDIT was deemed unsuitable for this purpose.
Personally I like the idea of using FEEDER_AUDIT and there is growing recognition that we need to expose more of the RM in the models for specific archetypes but the current specs seemed to debar the use of FEEDER_AUDIT for outgoing identifiers. 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 11:55, Peter Gummer <peter.gummer at oceaninformatics.com> wrote: > Grahame Grieve wrote: > >> The first is that in the archetype design we came up with (still be >> posed >> on CKM yet), there's a lot of identifiers present. These identifiers >> are >> required to deal with the interoperability aspects of the imaging exam >> report (i.e. PACS reigsters images with RIS, RIS provides report to >> EHR, EHR tracks identifiers so it can provide links to RIS/PACS >> resources as required). In particular, in several places there's slots >> for various DICOM UIDs. To me, these are IT issues, not clinical >> issues, so they shouldn't be part of the archetype design (on the >> basis >> that archetypes are *clinica* knowledge)- but I do know that we >> absolutely need these identifiers. Is there a policy about this? >> Note that I ask this question with wider issues about whether IT and >> interoperability concerns should be explicitly represented in >> archetypes. > > > > Hi Grahame, > > I believe what you're saying is right. This sounds exactly like what > the FEEDER_AUDIT class was designed for. See the the Common IM spec. > > Each LOCATABLE has an attribute called 'feeder_audit', of type > FEEDER_AUDIT. Within the FEEDER_AUDIT class, there are lists of > DV_IDENTIFIER where systems can store ids generated by the originating > system and other systems. The FEEDER_AUDIT also has an attribute > called 'original_content', where an image or a reference to the image > would be stored. > > Because COMPOSITION inherits from LOCATABLE, an obvious place to set > the 'feeder_audit' attribute might be on the composition. You could of > course prefer to set it on, say, the imaging exam OBSERVATION. > > This is an excellent example of something that is already catered for > in the reference model, and so it probably shouldn't be modelled in > archetypes. Unfortunately, current tools don't make the feeder_audit > attribute visible visible to modellers, so they are likely to > "reinvent the wheel", unaware that it's already available. (They're > designing "wheels" for the "car", but the car already has wheels.) > This is a problem to modellers: an important part of the model that > they are designing is to all intents and purposes invisible to them in > the archetype. > > - Peter > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical >
