Act.text and code.originalText

Text is being put into both originalText and act.text and we need guidelines. Last week's Vocab call (16-May-07) discussed this, resulting from the MnM/Vocab thread "question about Act.code.originalText vs Act.text" and InM/Vocab thread "Meaning of CD.displayName".

Here are some use cases and candidate representations, to prime the discussion.

Text Use Cases

In summary the use cases are:

- Sometimes there is a code

- Sometimes there is text that is orthogonal to that code

- Sometimes a short code is entered into UI that results in a code being found and selected.

- Sometimes a code is derived from narrative text entered, and you want to record that text (or fragment of it) specifically to show the code decision process.

- Sometimes a code would be displayed one way to an expert user (eg CXR for "Chest X-Ray"), but this would need spelling out in full to a less specialist user.

Fuller use cases are below, some more realistic than others (comments on how common they are are welcome).

Uncoded text use case

1 - Document centric system, supports narrative text only, in form of paragraphs, documents. Little structure, only authors of documents, and time of authoring

Suggested text representation: Act.text

2 - Text statement centric system, supports dated, attributed, possibly categorised and/or cross linked, units of text but no codes.

Suggested text representation: Act.text

3 - Code plus text based system, supports coded entries, and uncoded "text" entries. Entry in question has no code, no attempt is made to code it.

Suggested text representation: Act.text

-- variation: A coded system allows text only entries but has a rule that all entries must be coded. So behind the scenes a dummy code is added such as "text comment". This dummy code may be stripped when a message is sent based on it, and replaced with some other semantic marker.

Suggested text representation: Act.text

4 - System supports coded entries that can also have text associated. However the text is orthogonal to the code. Eg code says penicillin, text says "told patient come back in a week if not better".

Suggested text representation: Act.text

Code from text use cases

5 - Coded system, user enters (or clicks/selects) PV as abbreviation for full code 1234="Penicillin". The full string "Penicillin" is not shown to the user. 1234="Penicillin" is entered into notes. System doesn’t record the fact that PV was entered, since this is a user interface issue.

Suggested text representation: Act.code=1234, act.code.displayName="Penicillin" (mandatory), act.code.originalText="[nothing]"

Comment: it would be an unusual system to not offer the full text of "Penicillin" back to the user for confirmation.

6 - Coded system, user enters (or clicks/selects) PV as abbreviation for full code 1234="Penicillin". The full string "Penicillin" is not shown to the user. 1234="Penicillin" is entered into notes. System DOES record the fact that PV was entered.

Suggested text representation: Act.code=1234, act.code.displayName="Penicillin" (mandatory), act.code.originalText="PV"

7 - Coded system, user enters (or clicks/selects) PV as abbreviation for full code 1234="Penicillin". The string "Penicillin" IS shown to the user in response to their "short code"/"query string". User selects "Penicillin" perhaps by clicking or hitting return. System doesn’t record the fact that PV was entered, since this is a user interface issue (user could have entered PenV, peni, penic etc, or just used the mouse, or even voice commands).

Suggested text representation: Act.code=1234, act.code.displayName="Penicillin" (mandatory), act.code.originalText="[nothing]"

8 - Coded system, user enters an encounter record and adds text "diabetic review" and clicks the "reason" check box next to it to indicate reason for encounter being "diabetic review". Actual encounter gets coded with "seen in surgery" or similar code, orthogonal to the reason.

Suggested text representation: Act.code=4567, act.code.displayName="Seen in Surgery" (mandatory), RSON act relationship to another act with has act.text="diabetic review".

Alternative not recommended is: Act.code=4567, act.code.displayName="Seen in Surgery" (mandatory), act.reasonCode.code="[nothing]", act.reasonCode.originalText="diabetic review"

9 - Coded system, user enters (looks up via some shortcut) a code of "diabetic review", then adds supporting short or lengthy text "had chat with patient discussed diet and..."

Suggested text representation: Act.code=5678, act.code.displayName="Diabetic Review" (mandatory), COMP act relationship to another act with has act.text="had chat with patient discussed diet and...".

Alternative not recommended is: Act.code=5678, act.code.displayName="Diabetic Review" (mandatory), act.code.originalText="had chat with patient discussed diet and..."

After the fact coding

10 - User dictates or hand writes text "had chat with patient reviewed diabetes control and...". Later a medical secretary codes this into a system, adding a code of "Diabetic Review", based on their understanding of the text. The full text is not entered, and remains in paper/tape form only.

Suggested text representation: Act.code=5678, act.displayName="Diabetic Review" (mandatory), act.code.originalText="had chat with patient reviewed diabetes control and...."

Comment: The system may not natively support "original text for a code", so if the text was entered at all it would likely be in a general clinical comment field. How would the user then indicate that this text was used for the code selection?

11 - Coded system, user enters into the system an uncoded comment "had chat with patient reviewed diabetes control and....". Later, a medical secretary reviews this and adds a code for "diabetic review" to the same entry/record.

Suggested text representation: Act.code=5678, act.displayName="Diabetic Review" (mandatory), act.code.originalText="reviewed diabetes control" (to indicate which words were considered), plus COMP act relationship to another act which has act.text="had chat with patient reviewed diabetes control and....".

Possible other representation is to put all the text into original text and none into component/act.text, or to put all into both.

A third possible representation (only available if the system is constructed to store edits to existing records as separate actions) is to have the main user's text in act.text, with a component act relationship to a secondary act (different author and author time) that has the coded version, Act.code=5678, act.displayName="Diabetic Review" (mandatory), act.code.originalText="reviewed diabetes control"

Discussion

Note that none of the above use the construct act.code=NULL, act.code.originalText="the text". This is therefore deprecated in the view proposed above. If there is no code involved (perhaps not even an attempt to find a code), there seems no rationale for using code.originalText, other than the fact that this is sometimes convenient in the RIM. The answer to "what if there is no code" is therefore "yes, there really is no code at all, only text, which goes in act.text".

Sometimes code.originalText is employed because the text is used to somehow generate the code. But sometimes it seems to be used because you have text, but a datatype that only accepts a code. This appears to be a different use case.

There are RIM attributes that carry a particular semantic meaning eg reasonCode. To give a textual reason to an encounter, say, you could use act.reasonCode.originalText, and have no value in act.reasonCode.code. This seems to be text masquerading as a code, and if act.reasonCode allowed an ST or ED datatype it would be better to put text in with no reference to codes at all.

(Incidentally, reasonCode is not in the Clinical Statement pattern, since that tries to have a single way to achieve each representation (RSON act relationship in this case), even though it often standardises on the more verbose more flexible version.)

Act.code.originalText can work as a way to put uncoded text into an act, and it is less verbose that using act.text with less baggage around renderings and being affected by other attributes (see Act.text and Supplemental_text. This seems to be another kludge however, a workaround for there not being a RIM attribute called something like act.supportingText (with act.text really being act.representation)

The use of a pre-/post-coordinated term in a code doesn't appear to make any difference to the scenarios above. "Code" can be taken to be a "code group" in any form with or without qualifiers.

Displaying the results

There are several phases of operation to consider:

- original data entry

- possible secondary coding stage

- re-display in original system (not a messaging issue, but possibly illuminating)

- re-display in another system once messaged

In all the cases above, what would want to be shown to a user as part of a summary patient record?

A rule of thumb could be:

- Always show act.text

- Always show act.code.displayName

- Never display act.code.code (or other attributes not mentioned like codeSystem)

- Show act.code.originalText only if there is no act.code.code (but this construct may be deprecated)

- Never display act.code.originalText otherwise, since this is just audit data.