This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "CDA Suggested Enhancements"

From HL7Wiki
Jump to navigation Jump to search
Line 59: Line 59:
  
 
*How does document succession impact contained acts? For instance, in the case of a replacement document, one can use the RPLC relationship on a revised Act, so we could comment on this. In the case of a repudiation, all contained acts are impacted. [From Rene: I think that at least there should be some kind of warning or implementation guidance within the CDA standard. This need not be elaborate, but it could describe that those parties that extract data from CDA documents should consider the context of that data. The detailed rules may be as agreed upon at the affinity domain level. So I don't envision the CDA making normative statements about the application behaviour (HL7 shies away from that kind of statement anyway), but I expect it to remind users of the standard that this pitfall/implementation issue should be addressed - somehow. The exact policies have to be defined and agreed upon within or between organizations.]
 
*How does document succession impact contained acts? For instance, in the case of a replacement document, one can use the RPLC relationship on a revised Act, so we could comment on this. In the case of a repudiation, all contained acts are impacted. [From Rene: I think that at least there should be some kind of warning or implementation guidance within the CDA standard. This need not be elaborate, but it could describe that those parties that extract data from CDA documents should consider the context of that data. The detailed rules may be as agreed upon at the affinity domain level. So I don't envision the CDA making normative statements about the application behaviour (HL7 shies away from that kind of statement anyway), but I expect it to remind users of the standard that this pitfall/implementation issue should be addressed - somehow. The exact policies have to be defined and agreed upon within or between organizations.]
 +
 +
*In addition to saying that, for instance, Doctor X is the legalAuthenticator, there is a need to show that Doctor X is co-signing on behalf of the author and/or one of the authenticators.

Revision as of 11:51, 13 October 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.

CDA Suggested Enhancements

  • 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)?
    • This sounds nonsensical. STDC should document the statement that "Stylesheets shall never carry any semantics, as the use of stylesheets by the receiver is optional". Rene spronk 23:54, 16 Aug 2006 (CDT)
  • 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.
    • Requires extension of datatypes R2, a proposal has been made.
  • 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 implementation guides (e.g. CRS and CCD as a US realm example) to see where CDA itself can be more constrained.
  • Review common extensions used in implementation guides (e.g. CRS and CCD as a US realm example) as potential enhancements to CDA.
    • Look at the various uses of header's Participant in implementation guides (e.g. CRS and CCD as a US realm example), and see which should be further broken out as specific participants and/or that we have the necessary components.
  • 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)
  • 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)
    • Note: As long as the harmonization is universal in nature (and does not lead to US Realm sprcific constraints spilling over into the CDA architecture)
  • Per paul - should not include xsi:schemaLocation in examples.
  • How does document succession impact contained acts? For instance, in the case of a replacement document, one can use the RPLC relationship on a revised Act, so we could comment on this. In the case of a repudiation, all contained acts are impacted. [From Rene: I think that at least there should be some kind of warning or implementation guidance within the CDA standard. This need not be elaborate, but it could describe that those parties that extract data from CDA documents should consider the context of that data. The detailed rules may be as agreed upon at the affinity domain level. So I don't envision the CDA making normative statements about the application behaviour (HL7 shies away from that kind of statement anyway), but I expect it to remind users of the standard that this pitfall/implementation issue should be addressed - somehow. The exact policies have to be defined and agreed upon within or between organizations.]
  • In addition to saying that, for instance, Doctor X is the legalAuthenticator, there is a need to show that Doctor X is co-signing on behalf of the author and/or one of the authenticators.