Use of Identifiers in archetypes
hi Tom thanks So considering the notion of order and filler ids, and whatever other ids are required in a typical clinical process, it is clear that such things need to be accommodated in archetypes, if they are not already in the underlying reference model, because they are part of the information recorded. The clinical process can't proceed without them (and remember, they would still be needed with no computers and no IT - some identification system is unavoidable). ok ta I don't know about any such advice, and I am surprised by that, I would have said use DV_IDENTIFIERs. ok ta type: String - The identifier type, such as ?prescription?, or ?SSN?. One day a controlled vocabulary might be possible for this. I don't think the 'type' is confused modelling; it just indicates what kind of identifier it is. the identifier is a pointer to a thing. The thing has a type. The pointer to the type shouldn't carry the type of the thing it points to. (though I often think that debugging/troubleshooting would be simpler if it did!) You say that the type is the *type of the identifier*. Well, that's interesting. How can a pointer have a type? In the ISO datatypes, we added two properties to the II data type, scope and reliability. Reliability is under appreciated, but adding scope has had a series of interesting consequences. Possible values for scope: BUSN : Business identifier OBJ : Object identifier VER : Version identifier VW : View specific identifier The really interesting one here is BUSN. Here's the full definition: An identifier whose scope is defined by business practices associated with the object. In contrast to the other scope identifiers, the scope of the use of the id is not necessarily restricted to a single object, but may be re-used for other objects closely associated with the object due to business practice. Making this property explicit has forced everyone to re-evaluate their use of identifiers, and some interesting things have emerged. Firstly, we are crucially interested in two different types of identifier usage: what you might call direct and indirect. (At one time you referred to this division as real world identifier and technical identifier, but this isn't obvious in the tools, and I'm too lazy to look it up again). We have come to recognise that this is the same as a business identifier vs one of the other types. On further examination, we've found that business identifiers are almost exclusively linked with roles (RIM speak, sorry), and then where there are external registration authorities for the roles (patients, people, doctors, companies, etc) If by type, you mean things like scope or reliability, then ok. But the possible values need to be enumerated to make them useful to implementers. if by type you are referring to the kind of registration authority... then the lack of a controlled vocabulary field forces archetype designers to make the kind of registration authority explicit in the archetype so that the identifiers can be found and exchanged when required So the type is useless - in practice either it is not relevant or it's value is implicitly fixed. At least, I think so. I suppose I should scan the archetypes to check my assertion, particularly the demographics ones which are generally directly concerned with external registration authorities. anyhow, that's a side issue. Grahame
Use of Identifiers in archetypes
Hi Peter, Tom thanks Just take care to use FEEDER_AUDIT for ids generated in external systems, rather than assigned within the openEHR system, including by users of apps talking directly to the openEHR system. I'm not sure which way to parse that sentence Generally, about FEEDER_AUDIT, it's something I had missed, so I'll go and review it, but how does it manifest in the archetype editor? Ian: 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. because the identifiers weren't explicitly identified? Can you say why it was deemed unsuitable? thanks Grahame
Use of Identifiers in archetypes
Grahame Grieve wrote: Generally, about FEEDER_AUDIT, it's something I had missed, so I'll go and review it, but how does it manifest in the archetype editor? FEEDER_AUDIT isn't shown in the Archetype Editor at all. It's one of many parts of the reference model invisible within the tools, and so easily overlooked by modellers. As Ian said, there's growing recognition that future tools need to rectify this. - Peter
Use of Identifiers in archetypes
Hi There have been a few issues with DV_IDENTIFIER - largely that all fields are mandatory. This may mean that users puts stuff in that is not helpful. There is also no known set of things to use at any point although this could be expressed in a template (or archetype although this would not be appropriate). There is a WORKFLOW_ID on every entry that Ocean have been using to link data around a particular workflow - this is the PLACER_ID in HL7 v2. It allows observations, actions etc to be related to a particular instruction. This is working well and keeps things relatively simple. Feeder_audit is a great way to find information about feeder systems and is present in 13606 as well. It is not in the archetype (constrained) but should be visible soon in CKM. I would also suggest that we allow people to use the HL7/ISO datatype names for the models to aid use and familiarity. It will be a diminished set (openEHR compatible) but should meet all the needs of the modellers. Cheers, Sam -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Ian McNicoll Sent: Wednesday, 19 January 2011 8:32 AM To: For openEHR technical discussions Subject: Re: Use of Identifiers in archetypes Hi Grahame, The concern about FEEDER_AUDIT related to its use in outgoing service requests e.g. within referrals / lab requests etc. This is technically possible but against the intentions within the specifications as Thomas suggested in his eralier reply. Personally I would be happy to see the specifications change to allow FEEDER_AUDIT used in this way. 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 20:30, Grahame Grieve grahame at kestral.com.au wrote: Hi Peter, Tom thanks Just take care to use FEEDER_AUDIT for ids generated in external systems, rather than assigned within the openEHR system, including by users of apps talking directly to the openEHR system. I'm not sure which way to parse that sentence Generally, about FEEDER_AUDIT, it's something I had missed, so I'll go and review it, but how does it manifest in the archetype editor? Ian: 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. because the identifiers weren't explicitly identified? Can you say why it was deemed unsuitable? thanks Grahame ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
Use of Identifiers in archetypes
There have been a few issues with DV_IDENTIFIER - largely that all fields are mandatory that's pretty remarkable. really? This may mean that users puts stuff in that is not helpful. sure would. Grahame
