Datatypes R2 Issue 26

Introduction

There is a need to create a special datatype off ED for CDA datatype

An old motion from INM: Data types need to support data type requirements of CDA, In particular the narrative block should be available as a mime type for ED. And CDA should use data types properly.

Not sure now what the last bit is about, but we need to create the CDA datatype, and get them to use it.

? backward compatible.

Discussion

The concept is to create a special CDA narrative datatype. We can model it as a specialisation of ED. It would have a fixed mediatype (but not the standard CDA mediatype, that's for a whole document. so it would probably be XML).

The interesting thing about the CDA is the structured narrative - it's a little mini hypertext model. We can choose to model the CDA document at the abstract level as a plain sequence of bytes (plain ED) and ignore the content, or we can try to model the content. I recommend simply a plain ED.

At the xml level, we need to bind the CDA narrative datatype to the CDA narrative schema. This raises interesting ownership questions, specially in regard to ballot procedures. It would be right for the ITS sig to own the schema, but it ballots on a different cycle to structured documents.

Note From Charlie:

This is not just a CDA requirement -- it is needed in messages too where there is narrative that is related to the structured content -- having it hidden in the CDA schema is unacceptable if we are to share structures between CDA/SOA/MSG

Grahame: Agree. So, they key question is who takes ownership of the definition of narrative block, who defines it, and does it change with datatypes ballots or CDA ballots? If datatypes owns it, and it changes with datatypes, then the proposal to move it into datatypes is clean. Is it stable enough for Structured Documents to be prepared to do this?

Bob Dolin: The new requirements for narrative block markup have come mainly from SPL. Other non-clinical documents may have other requirements, but none have yet been identified that I'm aware of (see CDA Suggested Enhancements).

Grahame: Well, we can make it a flavor. But I'm giving some thought to exposing the content of the narrative in the abstract level - this would mean that we could write constraints against it at the abstract level

I would advise against that. Constraining the XML can be done by referring to a different schema. We already have CDAText and CDATitle. Gschadow 21:00, 9 May 2007 (CDT)

Why against it? generally we disapprove of writing an ITS specific constraint expression such as schema. How would I say in a template that I just want simple text in my structured narrative, no images? Should we provide a few constrained flavors? --GrahameGrieve 18:00, 13 May 2007 (CDT)

Against it because the CDA NarrativeBlock is outside the semantic scope of the data types. It is the nature of an ED that it encapsulates data and only minimally meddles with the internals of that. It is also the nature of NarrativeBlock that it is about representation, about XML, and schemas, not semantic meaning of information. Therefore v3dt and ED should not meddle with it even if it could. It's not our business. Constraining the schema is all we need to do. Gschadow 19:20, 13 May 2007 (CDT)

Mime Type

Another thing we need here is two mime types. A mime type for a whole CDA document, and a mime type for a structured narrative alone.

• mime type for whole CDA document: ?
• mime type for narrative: text/x-hl7-text+xml

BTW, following the argument in Datatypes R2 Issue 93, the CDA datatype is not a flavor, since it fixes and defaults the value for mime type.

Actually, this is an ITS problem. We do not hold that the MIME type is defaulted, only fixed. If the ITS can organise for defaulting the mime type, than it is welcome to do so.--GrahameGrieve 19:32, 20 June 2007 (CDT)

Misc

See Datatypes R2 issue 21 for endorsement of the concept from CQ

Links

Back to Data Types R2 issues