Difference between revisions of "CDA Suggested Enhancements"
| Line 1: | Line 1: | ||
'''NOTE:''' Membership on this list bestows no special privileges. The list is just a convenient catalog of various comments received along the way. Each of these suggested enhancements will need use case backing, a formal proposal, etc before being considered for CDA Release 3. There is no requirement that an item be on this list to be considered for CDA Release 3. There is no timeline for the balloting of CDA R3. | '''NOTE:''' Membership on this list bestows no special privileges. The list is just a convenient catalog of various comments received along the way. Each of these suggested enhancements will need use case backing, a formal proposal, etc before being considered for CDA Release 3. There is no requirement that an item be on this list to be considered for CDA Release 3. There is no timeline for the balloting of CDA R3. | ||
| + | |||
| + | o ------------------------------------------ o | ||
• Clarify the subject and recordTarget: If the context of a section or entry doesn't explicitly assert a Subject (remembering that the Subject may have been asserted higher up and propagates down through context conduction), one shall infer that the Subject is the RecordTarget. | • Clarify the subject and recordTarget: If the context of a section or entry doesn't explicitly assert a Subject (remembering that the Subject may have been asserted higher up and propagates down through context conduction), one shall infer that the Subject is the RecordTarget. | ||
Revision as of 01:51, 17 August 2006
NOTE: Membership on this list bestows no special privileges. The list is just a convenient catalog of various comments received along the way. Each of these suggested enhancements will need use case backing, a formal proposal, etc before being considered for CDA Release 3. There is no requirement that an item be on this list to be considered for CDA Release 3. There is no timeline for the balloting of CDA R3.
o ------------------------------------------ o
• Clarify the subject and recordTarget: If the context of a section or entry doesn't explicitly assert a Subject (remembering that the Subject may have been asserted higher up and propagates down through context conduction), one shall infer that the Subject is the RecordTarget.
• CustodianOrganization – why is phone number restricted to just 0..1?
• Add "entry" as allowable classCode for the Organizer clone.
• Remove the need for populating the narrative block (so long as a style sheet is attached)?
• ParentDocument.code should be changed from CD to CE.
• ID/IDREF and getting narrative block into datatypes - change outbound references to point to Act ID's rather than XML ID's, and deprecate the XML ID additions to the CDA schema.
• Add a discussion of our approach to defaults (?non normative): only declared for xml attributes, not used at all in choice box.
• Compare CDA constraints against those in CRS and CCD to see where CDA itself can be more constrained.
• Review all CRS and CCD extensions as potential enhancements to CDA.
• Allow for associations to be NULL with a particular null flavor (use of nillable attribute). (There are cases where the cardinality is optional, but you want to explicitly nill something with a null flavor)
• Look at the various uses of header's Participant in CRS and CCD, and see which should be further broken out as specific participants and/or that we have the necessary components.
• Define a canonical extension mechanism to use components of the Clinical Statement model that aren't part of the current CDA standard
• Add nonXMLBody/id
• For all vocabulary, list the Vocabulary Domain (along with coding strength, and OID), Value Set
• Clinical Statement Comparison / reconciliation
• Medical Records header Comparison / reconciliation
• Family history representation – compare / reconcile with Genomics family history representation
• All enumerated CNE domains should be x-domains (value sets) - eg. OrganizationPartOf.statusCode
• ServiceEvent vs. EncompassingEncounter - ordering provider - we have referrer on the encounter, but perhaps we need the ordering provider on the service event instead - this would cover ordering a test, or ordering a referral. or on Order for the ordering provider?
• Add entryRelationship.priorityCode
• Where we've constrainted CE to CS (ROI.code, languageCode) - consider changing to CE (per M&M recommendations that came out subsequent to release of CDA R2)
• Section-level authentication (? or possibly even more fine-grained – e.g. ICU flow sheet example)
• Digital signatures / digital rights management
• Consider use of ClinicalDocument.text rather than nonXMLBody, renaming NonXMLBody, and/or deprecating nonXMLBody.
• Review the differences in header Performer vs. body Performer to see if they should be reconciled. (e.g. Header Performed has a functionCode, whereas body Performer has a modeCode).
• The participations identified in the header do not correspond to the signature roles defined in ASTM E1762. Consider the implications of non-harmonization, and perhaps provide a mapping. ASTM E1762 includes a list of roles for participations. DICOM is considering the use of these by the security group. Consider comparison / gap analysis for CDA, R3 and bring back to committee (e.g. to review with Security committee)
• Per paul - should not include xsi:schemaLocation in examples.