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

CDA Suggested Enhancements

From HL7Wiki
Jump to navigation Jump to search

SDWG page.

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.

The initial ballot of CDA R3 is planned for September 2009. See also CDA R3 Formal Proposals, which contains formal proposals that have been reviewed and voted on by committee.

CDA Suggested Enhancements - New, for review

Suggested enhancements are closed as of End of Sept 2009. New suggested enhancements should be discussed with the Structured Document co-chairs.

CDA Suggested Enhancements - TO BE ADDED TO WORKPLAN

See CDA R3 Workplan Items

CDA Suggested Enhancements - FORMAL PROPOSAL NEEDED

The following items need a formal proposal to be submitted. Currently we are seeking owners for these formal proposals.

1. Masahura Obayashi, Nagayo-RHIE CDA implementation project (Japan): request that section.code be of datatype CD instead of CE. This because of a requirement to add a qualifier to the code. The underlying use-case is related to the measurement of 'mobility scores' at various points in time within the context of a stroke rehabilitation clinical pathway. There are multiple 'mobility score' sections within one single document, (according to protocol) 1 month after the stroke, 3 months after the stroke, etc. These time intervals are coded and would serve as qualifiers of the section.code.

2. Introduce "Level 4" to identify Entries that are linked (by means of content ID) to the section text. A level 4 document is a level 3 document *with content links*. Rene spronk 08:13, 21 April 2008 (CDT)

3. CustodianOrganization – why is phone number restricted to just 0..1?

4. Add "entry" as allowable classCode for the Organizer clone. [note: may be subsumed by other CDA model and RIM harmonization changes]

5. Remove the need for populating the narrative block (so long as a style sheet is attached)?

6. 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.

7. Add a discussion of our approach to defaults (?non normative): only declared for xml attributes, not used at all in choice box.

8. 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.

9. 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)

10. 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?

11. Section-level authentication (? or possibly even more fine-grained – e.g. ICU flow sheet example, reference lab)

12. Digital signatures / digital rights management (applies to signature.txt on participations; add as optional)

13. Consider use of ClinicalDocument.text rather than nonXMLBody, renaming NonXMLBody, and/or deprecating nonXMLBody.(Rick should review in terms of the outstanding proposal for nonXMLBody.)

14. 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 specific constraints spilling over into the CDA architecture)

15. Per Paul - should not include xsi:schemaLocation in examples.

16. 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. (Appears to be covered by current participants.)

17. Create clones of the <value/> element (inside an observation) that are pre-bound to specific datatypes, i.e. <physicalQuantity/> would be pre-defined as a PQ. This avoids the hack of having to use xsi:type every time you have a value, which is awkward at best, and unworkable in some tools. It may also limit the use of alternate schema languages to validate CDA documents (I don't belive RelaxNG understands xsi:type). I do not suggest removing the ability to do use xsi:type, just don't make it mandatory for all cases. 

  In the following observation:
     <observation classCode="OBS" moodCode="EVN">
         
         <statusCode code="completed"/>
         <effectiveTime value="200004071430"/>
         <value xsi:type="PQ" value="1.77" unit="m"/>
     </observation>
  you could replace
     <value xsi:type="PQ" value="1.77" unit="m"/>
  with
     <physicalQuantity value="1.77" unit="m"/>
     
  This would make authoring a lot easier (no need to refer to the datatypes spec 
  for each observation), and would make it possible to use tools that do not 
  support the use of xsi:type to redefine datatypes.

  For more reasons why the use of xsi:type is often frowned upon, refer to Norm's 
  blog entry on the subject: 
  http://norman.walsh.name/2004/01/29/trainwreck.
  After speaking with Dr. Dolin and others, it seems likely that making this 
  change will require input from M&M and probably a change to the XML ITS as well. User:Rgeimer
    • This is a bad idea. There is just one attribute. Pre-coordinating the name of the attribute with the type will mean the creation of unnecessary choice code when the type difference is not important. There will also be a profusion of names for different types - and it pretty much does exclude use of xsi:type - after all, if you create a physicalQuantity alternative, it will only be useful if no one can use <value xsi:type="PQ" anymore. Mr Norman Walsh may not like xsi:type, but he is silent on whether he thinks polymorphism is a bad idea or not. You'd still need to refer the datatypes spec for each observation, since that's what provides the definitions. --GrahameGrieve 16:48, 12 February 2008 (CST)

18. Simplify referencing external files. Seems like you have to jump through hoops just to link to a GIF. Maybe allow renderMultiMedia to reference a URL directly. Currently you need to do something like the following (some required markup removed): 

  <text>Erythematous rash, palmar surface, left index finger.
      <renderMultiMedia referencedObject="MM1"/>
  </text>
  <entry>
      <observationMedia classCode="OBS" moodCode="EVN">
          <value mediaType="image/gif">
              <reference value="lefthand.gif"/>
          </value>
      </observationMedia>
  </entry>
  While I can see the value in when you need to provide a lot of detail about an 
  image, it actually makes it impossible to reference images in a level 1 or 
  level 2 CDA document, unless I have missed something. So I propose this as an 
  alternative.
   <renderMultiMedia mediaType="image/gif" value="lefthand.gif"/>
   ... or if we decide to allow XHTML in the body:
   <xhtml:img src="lefthand.gif"/> 
  The downside is that this provides yet another way to reference external data 
  in a CDA.  User:Rgeimer

19. Should we make custodian mandatory vs. required? User:Rgeimer (We need to revisit the custodian role outside the core usage for exchange of information between providers.)

20. Clarify Relationship between a section and its entries. Narrative block issues: Resolve DRIV ambiguity (what does it mean with respect to the target of the OriginalText reference); Clarify if the target of a reference into the narrative block can be ID's other than those in the <content> tag; What if the narrative is rendered based on the displayName of the code - why would you use the originalText to point; Clarify if other than originalText can point to <content>; Conformance wording for when such referencing should be used; Do we need an extension to the ANY datatype that would allow any attribute to reference originalText? (e.g. do we need to reference from effectiveTime)

21. language code: Be sure not to overly constrain RFC-3066 (e.g. see Harry's ballot comment on CCD, row 6 in the Jan 2007 ballot reconciliation package)

22. Confidentiality codes: Work with CBCC (Community Based Collaborative Care) on consent and confidentiality code extensions for x_BasicConfidentialityKind. We potentially need the confidentialty code attribute at the entry level. May need to increase the cardinality of the confidentialty code attribute (across the board for CDA). (First issue, however, is more general and requires RIM harmonization proposal.) Need to consider how the confidentiality code in a document relates to the authorization processing which is policy based.

23. Allow an informant to also be an information system. (Are considering this for author and other roles.)

24. Review IHE profile for sending lab results in CDA to identify additional CDA R3 requirements. (Consider in light of harmonization Laboratory Result, Release 1.)

25. Provide guidance for image annotations.

26. We have the use case that we have more than 1 legally responsible authenticator. Suggest to change the cardinality of <legalAuthenticator> from 0..1 to 0..* User:kheitmann

27. Allow multiple telecom values for custodian. Right now there is no way to add a phone number and email address for a custodian. User:Rgeimer

28. Fixed font support for the narrative block

29. Representation of subject participant in the case of no family history should be reviewed in CDA R3. Representation of a statement about a group (e.g. grandparents lived into their 90s) should be clarified.

30. Narrative Issues 

- allow for alignment to applied to paragraphs. Otherwise people have to invent 1*1 tables simply to get paragraph alignment.--GrahameGrieve 17:06, 12 February 2008 (CST)
- remove align=justify from the table alignment properties - it's a paragraph alignment aspect--GrahameGrieve 17:06, 12 February 2008 (CST)
- clarify how setting a span on a colGroup makes sense --GrahameGrieve 17:13, 12 February 2008 (CST)

31. make explicit that negationInd defaults to false, including in the schema.--GrahameGrieve 08:58, 20 June 2008 (UTC)

32. add participation.uncertaintyCode (requires RIM harmonization proposal) for cases where the act is certain, but a participation is not. --GrahameGrieve 08:59, 20 June 2008 (UTC)

33. list APND and RPLC as on allowable combination in the restrictions of relatedDocument typeCode

34. from ServiceDeliveryLocation, add an IDENT RoleLink to a new role AccreditedEntity, with a scoper Entity of the accrediting organization. This allows the document to support conveying accreditations, as requested by the American College of Cardiology for imaging lab reports. -- Harry Solomon, 20 January 2009

from Feb 18, 2009: Here are several items for CDAr3 consideration:

35. Items discovered and unresolved when the EHR and SD WGs co-developed the "Implementation Guide for CDAr2 - Reference Profile for EHR Interoperability DSTU" (passed ballot in Jan 2008). This IG focuses on how CDAr2 can be used as the common unit of record for the EHR, based on EHR record requirements specified in the HL7 EHR Interoperability and Lifecycle Models (EHR/IM and EHR/LM). (Gary Dickinson)

  1. Non-patient specific documents/records (EHR/IM 3.6.2)
  2. Device/network location (address) of document/record origination or amendment (EHR/IM 3.13)
  3. Access control for document/record origination/amendment (EHR/IM 3.18.2)
  4. Audit entry/trail tracking document/record access/use (EHR/IM 3.19.3)
  5. Audit entry/trail tracking document/record transmittal/disclosure (EHR/IM 3.19.5)
  6. Audit entry/trail tracking document/record receipt (EHR/IM 3.19.6)
  7. Audit entry/trail tracking document/record de-identification or aliasing (EHR/IM 3.19.7)
  8. Audit entry/trail tracking document/record deprecation (EHR/LM 11.11)

36. Consent-based document/record access control (Gary Dickinson)

37. Expansion of confidentiality code - mechanics/specification of control AND applicability at attribute level (Gary Dickinson)

38. from Dan Russler Feb 18, 2009: One issue that has come up in Quality Reporting is the need for structured documents describing the nature and content of patient education and counseling delivered, e.g. stop smoking education and counseling; medication-taking education and counseling; surgical risk education and counseling, etc. Observations on patient understanding of the education also needs to be included. Pt signature on receiving the education and counseling should be supported. Note, that this signature requirement is different from collecting a patient consent signature. These patient education-related activities should be considered within the context of CDA R3 Entry level requirements.

39. from Helmut Koenig September 4, 2009: Add order participations for service event(s) to allow for conveying information on referring/ordering physicians.

40. from Helmut Koenig September 4, 2009: Introduce "preliminary flag" (suggested values: "preliminary", "final") for CDA documents. DICOM CP 931 specifies that label for DICOM SR reports and it would be beneficial to align the standards.

41. from Victor Brodsky User:VictorBrodsky September 30, 2009: Introduce <code codeSystemServerURL="URL" codeSystemServerMethod="LDAP-ISO11179-1"> (suggested value for codeSystemServerMethod shown) for CDA documents and code elements of CS, CV, CE, SC, PQR; also for routeCode, statusCode, targetSiteCode and all others where code="" may be used, for consistency. I have reviewed the CDA R2 standard document and everything in my recent email is addressed by the CDA R2 attributes of < code > except the pointer ( codeSystemServerURL ) to a local (or global), externally accessible vocabulary server which would be able to respond to query regarding a provided code with a definition and a value set. Since specifying a server implies a method of communication with it, I also propose adding a codeSystemServerMethod attribute in order to remain futureproof. In the case of such a Vocabulary Dictionary reference, "code=" becomes the unique data element ID as kept by the specified vocabulary server and using which the server can be queried; "displayName=" and "value=" for the code remain as they are, "codeSystem=" becomes the unique Dictionary ID as kept in the referenced Vocabulary/Dictionary Server (since a server can maintain multiple dictionaries), "codeSystemVersion=" and "codeSystemName=" also describe the dictionary. Details are in my email sent to Co-Chairs of this group. Please do contact me with any questions, as the addition of these two attributes will greatly impact the development of a standardized anatomic pathology report. As it stands now, the amount of various value sets behind data elements of College of American Pathologists Cancer Checklists for cancer diagnosis keep changing and will continue to do so according to clinical need. Including the entire value set along with each < code > is impractical and not including it impedes understanding of the received report (Was cellularity=low the lowest possible value? etc). Referencing an externally accessible vocabulary server for each code allows the sender to clearly define each field and provide entire value sets; it would allow documents to continue to flow from institution A to institution B when a new data element is added to the report by A without triggering an error at the recepient end as it would be able to instantly rebuild its schema and even validate the specific received value against A's vocabulary server's value set. With the addition of these two attributes the College of American Pathologists would be able to create a cancer checklist server, and the documents referencing it would be able to instantly pull updated value sets directly from it.

42. from Victor Brodsky User:VictorBrodsky September 30, 2009: Introduce <code codeSystemConfidence="text-value-here". Cancer diagnosis is often provided along with a phrase noting the confidence of the responsible pathologist and expressing whether the expressly provided diagnosis is the only possibility. We can argue about the necessity to eliminate the need for this and about how wonderful it would be if all pathologists would agree on everything, and if various evidence would 100% support a given diagnosis, however this is not the case. As a simple example several crucial immunohistological stains of tumor tissue may support several diagnostic possibilities (stain A and B being positive usually means diagnosis #1 is correct, while stain C being positive usually means diagnosis #2 is correct according to an authoritative textbook; however for the case at hand, all three are positive.) You can see the sample values here: Confidence Value Set example. As you can see, such sticky issues only reiterate the need for the recepient to see the entire value set, thereby emphasizing the need for the codeSystemServerURL="URL" and codeSystemServerMethod attributes above to reference the vocabulary dictionary which would maintain the value set, especially given that every pathologist prefers their own "confidence modifier" phrase.

43. from Victor Brodsky User:VictorBrodsky September 30, 2009: For <content revised="delete"> etc. would it be possible to add a "revisedBy="", revisedByDisplayName="" and timestamp="" attributes? If the resident or fellow composes the diagnosis portion of the document, a secretary transcribes the clinical history from the requisition form, another secretary starts voice transcription of the gross description today, and a third one completes the voice trascription of the gross description tomorrow (because some specimen parts came in the next day), while the accessioners transcribed part names, an attending's secretary typed up the final diagnosis, and the attending physician himself edited it before finally adding his signature, a single document's path inside a pathology laboratory can become complicated. Since the revisedBy="" could uniquely identify the person to a given organization, it would also be good to provide an ldap server reference.

44. from Victor Brodsky User:VictorBrodsky September 30, 2009: Since <content revised="delete"> exists for the text block, we would need to have a similar tag for the < code > coded values as well. What I mean is that if the entire document is mostly a check list of structured data values, as it often is in pathology, and is first filled out by a resident and subsequently changed by an attending physician, this would allow to maintain a trail array of previous values for codes (which along with revisedBy="" and timestamps above would give an editing trail for a structured document. These trails can be maintained for internal audits and reports and stripped before the document is sent out.

45. from Victor Brodsky User:VictorBrodsky September 30, 2009: Introduce <content deIdentification="remove"&gt(possible values: remove / encrypt) since the software in front of the person authoring the document has the best chance of capturing whether a given text segment would allow patient identification ("Patient mentioned that a classmate by the name of George Brown pushed him onto the road when the cab hit him" it would be great to allow it to label a text fragement as such to help de-identify the document later for research.

46. from Victor Brodsky User:VictorBrodsky September 30, 2009: Introduce <content displayRule="unobstructed"&g; and <code displayRule="unobstructed" (possible values: unobstructed / verbatim / 0.7cmMin / required ) with duments being viewed on smaller and smaller screens (an iphone today, a cellphone watch tomorrow?) important information within the report must be emphasized to the recepient. Explanations for possible values:

    • 0.7cmMin = minimum height of font in centimeters (of course it would be better to make it into a separate element with height value)
    • unobstructed = display entire content of element on the screen without the need to scroll the text box (unless this is impossible due to restriction above due to the size of the screen
    • verbatim = do not replace by a a "flag" or other symbols - display as is
    • required = the element must be shown to recepient before the document is closed.

At this stage we could of course avoid all the trouble above by adding just one displayRule="emphasize" value and let the recipient software decide how to handle the emphasis.

47. [Owner GGrieve] Add some information about employment status for both Person and Patient (GGrieve). Use case: to allow the nature of the patients employment to be reported (stats purposes, I believe) and that of the care providers. (checking this....) Visio Diagram for Employment enhancements (notes: how much is this required. Is it really header or should it be body - formal proposal should address this, along with CMET related issues - not in assigned, is in patient)

48. [Owner GGrieve] Add support for reporting care provider specialties (GGrieve). Use case: the specialty of the care provider is an important element to report in clinical documents. Visio Diagram for Field Of Practice

49. [Owner GGrieve] Surface Document.completionCode in a CDA document (GGrieve). Use case: We need to represent the completion code of the report that the document represents. This is not the status code of the document -it's complete. It's not the status code of the service event either. It's not the current status of the report either - it's the status of the report at the time of completion of the document. (note: this is not dynamic, document is not revised when status changes. Committee was uncomfortable with the use of the term "complete". Also, need to clarify the relationship between document authentication and the status of the report - no ambiguities to be accepted)

50. Develop a Plan of Care structured document. [OUT OF SCOPE FOR CDA R3]

51. Would like to have a common definition of advance directive – esp between ASTM, HL7, NUBC (contact: Bob Davis), and Public Health Data Standards Consortium (contact: Bob Davis) for future implementation guides that reference advance directives. [OUT OF SCOPE FOR CDA R3]

CDA Suggested Enhancements - FORMAL PROPOSAL PRESENT

  • [FORMAL PROPOSAL PRESENT]
    • 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)
    • See Stylesheet Semantics for full discussion (a summary of an e-mail exchange) of this topic.
    • See Clarify Stylesheet Semantics for the formal CDA R3 proposal related to this issue.
  • [FORMAL PROPOSAL PRESENT] Consider allowing a true subset of XHTML for the narrative block (in the XHTML namespace), and only use specific elements in the HL7 namespace when absolutely necessary. This will make rendering CDA documents very simple. User:Rgeimer
    • Sounds like a good idea at face value, but I'm not so sure it's a good idea. As well as being a constraint on XHTML functionality, narrative block also extends it and subtly redefines the notion of a document. So I don't see that it would really make any difference to implementers. Running a transform is pretty simple...--GrahameGrieve 16:48, 12 February 2008 (CST)
  • [FORMAL PROPOSAL PRESENT] From Lcerulli: CDA R3 should bridge the gap between clinical and administrative content. Clinical Documents often contains also Financial or Administrative infromation that are part of the document itself (money paid by patient, exemptions, ..etc). Structured classes already exist in HL7 domains so the CDA R3 should provide a way of incorparating or referencing this kind of classes wrapped in the same CDA R3 architecture or if not possible in a brand new administrative document architecture that can be cross referenced. User:Lcerulli
  • [FORMAL PROPOSAL PRESENT - "CDA R3 Proposal - Append, Edit, Correct Enhancements"] Add a means to capture the reason for why a document was replaced with a new version. Ideally this would consist of a code and a text description. User:Rgeimer
  • [FORMAL PROPOSAL PRESENT] Need a header for patient's registered/normal General Practitioner (PCP, lots of names all round the world). Has been mapped as Primary Information Recipient, but this is not right. Can be done using functionCode on participation on service event, but only when the service event is the right kind of service event. See also CCD 3.17 --Grahamegrieve 05:37, 27 May 2009 (UTC)
  • [FORMAL PROPOSAL PRESENT] introduce support for further document relationship in header (this way one can see that e.g. a lab report has been used in a discharge summary without interpreting all level 3 entries) -- Frank Oemig 16 July 2009
Retrieved from "https://wiki.hl7.org/w/index.php?title=CDA_Suggested_Enhancements&oldid=27873"