These comments refer to V1.4.2
3.1 The class Locatable has a name, which is of type DV_TEXT.
DV_TEXT seems inappropriate here, it includes formatting,
hyperlinks, coded values, etc. I would've thought that string
was appropriate?
actually, this comment also applies in many other places when
DV_TEXT is used. Other cases are the names of the items in
a LIST_S, and the use of DV_CODED_TEXT for a null flavour
Grahame
Grahame Grieve wrote:
These comments refer to V1.4.2
3.1 The class Locatable has a name, which is of type DV_TEXT.
DV_TEXT seems inappropriate here, it includes formatting,
hyperlinks, coded values, etc. I would've thought that string
was appropriate?actually, this comment also applies in many other places when
DV_TEXT is used. Other cases are the names of the items in
a LIST_S, and the use of DV_CODED_TEXT for a null flavour
Hyperlinks and formatting are still being discussed. Hyperlinks should probably only be in data, not in name values as you say. However, I don't know if we yet have enough experience to say how they will be used even there. I suspect that invariants should be added to some places like LOCATABLE to prevent hyperlinks and formatting being present in the name. This can be done in any class, but it would be better to know if we have to keep them at all in tis class, or put them elsewhere (e.g. DV_PARAGRAPH...)
A plain String isn't appropriate because what is required is:
- a string value
- the language (consider that some words appear the same in multiple languages but have different meanings)
- the possibility of the value being coded rather than just an entered string.
DV_TEXT allows all of these. The question is whether they hyperlink & formatting should be allowed in some contexts - I agree that this needs to be more thoroughly considered.
thoughts?
- thomas beale
Grahame Grieve wrote:
These comments refer to V1.4.2
3.1 The class Locatable has a name, which is of type DV_TEXT.
DV_TEXT seems inappropriate here, it includes formatting,
hyperlinks, coded values, etc. I would've thought that string
was appropriate?actually, this comment also applies in many other places when
DV_TEXT is used. Other cases are the names of the items in
a LIST_S, and the use of DV_CODED_TEXT for a null flavourHyperlinks and formatting are still being discussed. Hyperlinks should probably only be in data, not in name values as you say. However, I don't know if we yet have enough experience to say how they will be used even there. I suspect that invariants should be added to some places like LOCATABLE to prevent hyperlinks and formatting being present in the name. This can be done in any class, but it would be better to know if we have to keep them at all in tis class, or put them elsewhere (e.g. DV_PARAGRAPH...)
A plain String isn't appropriate because what is required is:
- a string value
- the language (consider that some words appear the same in multiple languages but have different meanings)
I thought all the content of a single transaction was confined to a single language?
- the possibility of the value being coded rather than just an entered string.
yes, indeed. But the DV_TEXT and DV_CODED_TEXT are too complex to be used
as constructs where simple coded values are required. They may be appropriate
for clinical coding, but in these simpler "infrastructural" coding, it's not
so clear
I'm not necessarily arguing for a plain string. There has to be
code, code system, version, text - ideally that would be all in a
general infrastructural coding situation?
Grahame
Grahame Grieve wrote:
I thought all the content of a single transaction was confined to a single language?
there is one point of view that all of a single _version_ must be a single language, and another that says even this won't be realistic due to patient respones in other languages.
- the possibility of the value being coded rather than just an entered string.
yes, indeed. But the DV_TEXT and DV_CODED_TEXT are too complex to be used
as constructs where simple coded values are required. They may be appropriate
for clinical coding, but in these simpler "infrastructural" coding, it's not so clear
DV_CODED_TEXT is pretty simple:
value[1]: STRING
definition[1]: COORDINATED_TERM
language[1]: COORDINATED_TERM
mappings[0..1]: LINKED_LIST [TERM_MAPPING]
formatting[0..1]: STRING
hyperlink[0..1]: DV_URI
I agree that it could be argued that formatting should be applied in some other way (there used to be jsut a general purpose "emphasis" in GEHR for example). Whether hyperlinks should be disallowed in basic cases in the reference model is debatable as well. The ability to use mappings will always be needed. In most cases, an instance of DV_CODED_TEXT will have just the fields:
value[1]: STRING
definition[1]: COORDINATED_TERM
language[1]: COORDINATED_TERM
where a COORDINATED_TERM is:
code_string[1]: STRING
terminology_id[1]: TERMINOLOGY_ID -- the data of this is a STRING
I can't see getting out of it more simply than that.
- thomas beale
The context of any entry in the EHR is that it is the view, the perception,
of the person that authors it that is recorded in the entry.
It will be confusing to write part of the entry in English and another part
in sanscrit. As it is confusing to use the HL7 2.x syntaxe in one part and
that of Edifact in an other.
What patients tell in what language is most of the times via the perception
of the healthcare provider that is documenting the healthcare process.
GF
-- <private> --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
+31 252 544896
+31 654 792800