Hi Colin, that’s what I meant with my second paragraph (That way, if there’s no structured INSTRUCTION or there are no mapping rules…), i.e. define conditions under the software knows to show or hide the narrative part for data input.
(attachments)
![]()
![]()
Hi Colin, that’s what I meant with my second paragraph (That way, if there’s no structured INSTRUCTION or there are no mapping rules…), i.e. define conditions under the software knows to show or hide the narrative part for data input.
![]()
![]()
Hi Pablo –
Yes, all this can be relevant, however…
My main point was to include the key role of local clinical leads and safety review processes within a particular implementation programme. In the present state of the art (aka until we have a mature evidence-based methodology available to support locally specific implementation decisions rather than relying on theory or opinion) there’s a need for technologists (who tend to like rules, the more “sophisticated” the better…) to exercise self-discipline & regard abstract rules as only a starting point for pragmatic discussion in a particular context. Trade-offs between various ways to use narrative (as discussed earlier in this thread) with other functions such as search & analysis would form part of such a pragmatic discussion.
Regards,
Ann W.
Ann M Wrightson
Pensaer TG | Lead Technical Design Architect
Gwasanaeth Gwybodeg GIG Cymru | NHS Wales Informatics Service
Caernarfon: Ffôn/Tel: 01286 674226 Pencoed: WHTN: 01808 8940 Ffôn/Tel: 01656 778940
Symudol/Mobile: 07535 481797
Indeed, I would say we (technologists) need to work alongside with local clinical leaders, safety review processes and constant audits focused on data flows, processing and use, not only as discussions previous implementation, but we must work together continuously throughout the project, improving the process while implementing it. Technology and rules are good (and feasible) at a certain point, after that, we need human intelligence (from domain experts) to help us out, e.g. to extract information from data, to set the right codes, to structure free text, to link together fragmented pieces of information, etc.
Of course this goes far away from my original question, but is always good to exchange opinions. My question was focused on knowing a very basic set of rules of how to interpret and handle possible semantic overlaping between nodes inside the same archetype. Those rules are something that can be implemented easily in an application, but the rules of how to derive structured/coded information from free text are in other league (for people smarter than me and/or multidiscipinary teams).