Download CDA Open Issues

1 CDA Open Issues: (August 1, 2002)
1.1.1
1.1.2
1.1.3
1.1.4
1.1.5
1.1.6
1.1.7
1.1.8
1.1.9
Model/Use of RIM
HMD
Vocab
ITS
Changes for Level One
Required additions for Levels Two & Three
Prose
Sample XML Instance
MISC
1.1.1 Model/Use of RIM
1. Identification of changes required due to current RIM and current data types -- ?
2. Create body R-MIM: need requirements first, especially for rendering -- Bob, Calvin,
Liora
3. Review clones from other committees against our proposed models
4. Include: caption with free text and link for each section; local_markup; link_CDA
5. Medications – need to review modeling. These aren’t really “events”. In some cases,
it is the patient saying what they are taking. In some cases the information comes
from a pharmacy system. In some cases, a family member brings in bottles. Need to
review how to express the “PRN” portion of a prescription.
6. Allergies – need to review modeling. How to link the allergy to the associated
reaction?
7. Need to review the correct values for Act.cd in in the case of diagnoses, allergies,
allergic reactions, etc (for instance, are these “prior diagnoses”, “findings”, etc)
8. Should we indicate whether or not the structured data fully encodes the narrative?
9. For CXR example – how to know you’re referring to some external object? (The
example uses an Act_relationship with type_cd = “REFR”)
10. Where/how do we inherit the date of an observation? Or do we need to include this
for every observation?
1.1.2 HMD
11. replace HMD with merged MRM/CDA HMD (change db #21) -- Bob
1.1.3 Vocab
12. Evaluate our use of RIM vocabulary -- ?
13. Role of participant: Should CDA convey the role or specialty of the author (attending,
cardiology, …) (should we re-examine the use of the function_cd field?) -- Bob to call
Steve Brown
1.1.4 ITS
14. General choices: 1) CDA-specific modifications to V3 ITS; 2) general modifications to
V3 ITS; 3) modify CDA to work with V3 ITS
15. Known discrepancies with V3 ITS:
 CDA has nested sections that mix with nested entries: We raised the issue of mixed
content and resolved to examine it on a case by case basis. (7/02/02)
 XML Lang attribute
 act.txt is a highly specialized type, only defined by an XML DTD
16. ITS(s): W3C Schema? DTD? RELAX NG? Decide normative status of each. Bob,
Amnon
17. Validation: Make sure the ID/IDREF for originator, etc are correct.Bob
1.1.5 Changes for Level One
o Link CDA: 3.3.2.4.3:
The group reached consensus on the relationship of strongly linked documents as follows:
 link_cda can have any authenticated document as a target
 authentication on the parent document means: “I authenticate that when I signed this document it had
this link and that I reviewed (but did not authenticate) the target of the link”.
 link_html will remain as a reference link
Note that we did not address directly the issue of link naming. Absent a decision to the contrary, names will
stay link_html and link_cda, but this issue could be raised again. (7/02/02)
18. Cardinality of <fulfills_order>, should be changed (change db #20)
19. Referenced coordinates: Modeled as a discreet observation that refers to the
referenced coordinate. (If so, need to add an Act_relationship in the R-MIM); Also
needs relationship to linked images (e.g. for x-rays); Need AR from Observation to
A_Ref_Coord -- ?? ITS, rendering issue?
20. consider change to MIME-packaging per Gunther’s suggestion (ask J. Borden)
21. We discussed the question of whether or not to add markup to future versions of Level One.
We resolved to review this on a case by case basis. The general rule for this review should be
maintenance of the Level One ease of implementation and easy migration to HTML. (minutes
7/02/02)
22. XFRM: The criteria for a “transformed” document (document relationship equals XFRM) are
that “markup” changes, not clinical content. Amnon asked how to distinguish this and Calvin
asked if this implied the document was XML. The group consensus was that the meaning
should be that the human readable content of two documents related through XFRM should
be equivalent. The group decided that a transformed document is not a replacement. The
meaning of “transform” as defined by CDA should be clean and consistent (7/02/02)
1.1.6 Required additions for Levels Two & Three
23. We discussed the definition of CDA Levels Two and Three. In general, Level Two will
constrain the structures of Level One while Level Three adds markup for observations and
procedures. The enriched Level Three document can then be constrained. We discussed, but
did not resolve, the question of constraint on Level One entries -- if a table cell is constrained,
does that make the resulting specification a Level Three document? (7/02/02)
24. Coded_entry in Levels Two & Three? should we maintain the distinction between
caption_cd and coded_entry?
25. Need a better understanding of how all the pieces can or should fit together:
 Need to review SNOMED hierarchies: Findings, Context-dependent
categories, Observable entities, Observations procedures, Interpretation of
Findings, Qualifier values.
 Pre- vs. Post-coordination of codes (see Dolin RH, Spackman KA, Markwell
D. Selective Retrieval of Pre- and Post-coordinated SNOMED Concepts. Fall
AMIA 2002. In Press).
 Lab and Clinical LOINC codes.
 ICD-9-CM and other administrative mappings (since at times it may be
preferable to use codes that map to ICD-9-CM)
 RIM attributes: Negation indicator, Context, Observation.cd vs.
Observation.value.
1.1.7 Prose
26. Clarify use of confidentiality codes; (change db #21)
27. Update:
 DTD comments

appendices
28. Add section on backward compatibility: We discussed backward compatibility and
resolved to document deprecated markup and let the CDA constituency guide the outcome
through the ballot process. Our principles will be that we remain one transformation away
from earlier CDA specifications and that we “seek stability” of design. At the same time, we
have to recognize that RIM 0.98 which is the basis for CDA 1.0 has undergone substantial
revision over the past two years. (7/02/02)
29. Update section on when to use MDM vs. ORU (Scott)
30. Document XFRM to <document_relationship.type_cd> to indicate that document
transforrmed from source (change db #17)
31. Document that retired the Patient_encounter.practice_setting_cd attribute; Indicate
that the PracticeSetting vocabulary domain can be used for the Role.cd attribute; Remap the current CDA <practice_setting_cd> to be derived from Role.cd, using the
PracticeSetting vocabulary domain; add Practice_setting values. (change db #21)
32. Document organization as potential intended recipient (change db #19)
33. Validation & conformance: We discussed requirements for validation and conformance.
These are currently discussed in a non-normative appendix to the specification. Bob
volunteered to re-write these and move them into the normative section of the document
(7/02/02)
1.1.8 Sample XML Instance
34. The sample will be updated as decisions are made, to reflect what a valid and
conformant instance will look like.
35. Some of the LOINC section codes in Bob’s NG CDA are made up. Need to validate
(and make sure needed section codes are in LOINC).
36. Things to add:
 Calvin’s Vital signs table
 Section that starts off with entries before there is a nested section.
 Context/Inheritance
 An in-office procedure (e.g. suture removal)
 Review modeling of units within observation values.
 Flavor of NULL (e.g. for Chem-7)
1.1.9 MISC
37. What is the down-side to just using HTML in the Act.txt field?