CDA Suggested Enhancements

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

• [ADD TO WORKPLAN] Rewrite section on backwards compatibility. Bring in line with overall v3 compatibility rules, document that the safe (semantic) option is to only map the human readable parts. Rene spronk 11:44, 18 January 2008 (CST)

• [ADD TO WORKPLAN] 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.

• [ADD TO WORKPLAN (make them consistent)]ParentDocument.code should be changed from CD to CE.

• [ADD TO WORKPLAN] Review general header constraints template

• [ADD TO WORKPLAN] Add nonXMLBody/id

• [ADD TO WORKPLAN] For all vocabulary, list the Concept Domain, coding strength, OIDs, Value Set, static/dynamic, etc.

• [ADD TO WORKPLAN] Reconcile with existing models, to include:
  • Clinical Statement
  • Medical Records header
  • Family history representation / Clinical Genomics model
  • Pharmacy (e.g. use of CAGNT (to match REPC_RM000021UV), ADMM (to match REPC_RM000021UV), MAT (to match REPC_RM000021UV). (Modify model so that one can be allergic to other than manufactured materials; Enable the ability to indicate dose form and concentration in separate fields).
  • Patient Care
  • Lab (e.g. requiring effectiveTime for lab results, add code attribute to SpecimenRole / compare with specimen CMET, age/sex conditions for reference ranges).

• [ADD TO WORKPLAN] All enumerated CNE domains should be x-domains (value sets) - eg. OrganizationPartOf.statusCode

• [ADD TO WORKPLAN] Add entryRelationship.priorityNumber

• [ADD TO WORKPLAN] Where we've constrained CE to CS (ROI.code, languageCode) - consider changing to CE (per M&M recommendations that came out subsequent to release of CDA R2)

• [ADD TO WORKPLAN] Review the differences in header Performer vs. body Performer to see if they should be reconciled. (e.g. Header Performed has a functionCode (attending, participating...) , whereas body Performer has a modeCode (electronically, etc.) ).

• [ADD TO WORKPLAN] [SEE in conjuction with [open proposal]http://wiki.hl7.org/index.php?title=CDA_R3_Proposal_-_Append%2C_Edit%2C_Correct_Enhancements] 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.]

• [ADD TO WORK PLAN] How does region of interest work for vector graphics? (Currently expressed only as pixels, not scalable for DICOM or vector graphics.)

• [ADD TO WORK PLAN] Add support for GOL/RSK and GOAL/RISK to the entries. User:Kboone (Will be addressed through adoption of Clinical Statement &/or the RIM)

• [ADD TO WORK PLAN] Add a nullFlavor attribute for section/text to provide a way to identify that no information was provided for a section that might otherwise be required. Using section/@nullFlavor is not appropriate, because then the section could not have a code to identify what kind of section had no information. User:Rgeimer In theory, every data type should carry a null (inherited from ANY). Review in light of data types 2.

• [ADD TO WORK PLAN] The use of text.reference and code.reference should be included in the examples in the standard to help clarify that code / originalText should only be referencing the narrative block when the narrative block contains original text.

• [ADD TO WORK PLAN] clarify whether nested tables and footnotes are allowed in the narrative block--GrahameGrieve 17:06, 12 February 2008 (CST)

• [ADD TO WORK PLAN] adopt Data types R2 (should be done as a R2.1 release!)--GrahameGrieve 08:58, 20 June 2008 (UTC)

• [ADD TO WORK PLAN - will be addressed as part of model bake off - done] remove constraint typeCode <= ActRelationshipEntryRelationship on entryRelationship and external links to allow for all typeCodes in order to support richer semantics -- Frank Oemig 16 July 2009

• [ADD TO WORKPLAN] Use the human identifier pattern consistently thoughout CDA (see MnM hot topic on design patterns) Visio Diagram for OtherID extensions used in Australia --Grahamegrieve 06:00, 27 May 2009 (UTC)

• [ADD TO WORKPLAN] from Doug Pratt September 10, 2009: Work with other committees (including OO and Patient Care) to develop a common generic model constraint mechanism that yields the same content representation for messages and documents.

• [ADD TO WORKPLAN] In the case of multiple preconditions, are they to be AND'd or OR'd?

• [ADD TO WORKPLAN] All content dealing with the prescription, dispense, or administration of medication should be drawn from the Pharmacy D-MIM, and should (MUST?) be based on CMETs maintained by the Pharmacy WG. This is a test case for the design principle that CDA R3 documents should be consistent with existing messages, as far as their structured domain-specific content is concerned.

• [ADD TO WORKPLAN] Allow deceasedTime for Patient (GGrieve). Use case: Clinical documents may be produced after the patient as passed away. (Also deceasedInd)

• [ADD TO WORKPLAN] Allow IntendedRecipient.Code (GGrieve). Use case: Australian discharge summary requirements include the role the intended receipient is playing in regard to the patient as justification for them getting the clinical document (family, gaurantor, care provider, etc) (possible associated discovered issue: HLTHCHRT (health chart) is not a kind of person) (analysis notes: this may be extension to classCode - for modelling review (for instance, classCode could be Guarantor, but we are not asserting that this is guarantor, but that in this role the report is intended for them). This is strictly limited to intent of document, and not intended to cover workflow issues that arise after the document is written)

• [ADD TO WORKPLAN] Add a Remote Consultation ActRelationship (GGrieve). Use case: teleconsultations are growing in popularity, but there is a requirement to report that they occured, who provided them, and where. Visio Diagram for Remote Consultation enhancements (this is not added to the workplan to do per se, but to ensure that the development of clinical statement provides enough sophistication to support this use case) (related item: address e-consultations - in clinical statement, document types, and encompassingEncounter)

CDA Suggested Enhancements - FORMAL PROPOSAL NEEDED

• [FORMAL PROPOSAL NEEDED] 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.
• [FORMAL PROPOSAL NEEDED] 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)

• [FORMAL PROPOSAL NEEDED] CustodianOrganization – why is phone number restricted to just 0..1?

• [FORMAL PROPOSAL NEEDED (may be subsumed by other CDA model and RIM harmonization changes)] Add "entry" as allowable classCode for the Organizer clone.

• [FORMAL PROPOSAL NEEDED] Remove the need for populating the narrative block (so long as a style sheet is attached)?

• [FORMAL PROPOSAL NEEDED] 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.
• [FORMAL PROPOSAL NEEDED] Add a discussion of our approach to defaults (?non normative): only declared for xml attributes, not used at all in choice box.

• [FORMAL PROPOSAL NEEDED] 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.

• [FORMAL PROPOSAL NEEDED] 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)

• [FORMAL PROPOSAL NEEDED] 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?

• [FORMAL PROPOSAL NEEDED] Section-level authentication (? or possibly even more fine-grained – e.g. ICU flow sheet example, reference lab)

• [FORMAL PROPOSAL NEEDED] Digital signatures / digital rights management (applies to signature.txt on participations; add as optional)

• [FORMAL PROPOSAL NEEDED] 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.)

• [FORMAL PROPOSAL NEEDED] 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)

• [FORMAL PROPOSAL NEEDED] Per Paul - should not include xsi:schemaLocation in examples.

• [FORMAL PROPOSAL NEEDED] 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.)

• [FORMAL PROPOSAL NEEDED] 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)

• [FORMAL PROPOSAL NEEDED] 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
  

• [FORMAL PROPOSAL NEEDED] 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.)

• [FORMAL PROPOSAL NEEDED] 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)

• [FORMAL PROPOSAL NEEDED] 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)

• [FORMAL PROPOSAL NEEDED] 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.

• [FORMAL PROPOSAL NEEDED: OUT OF SCOPE FOR CDA R3] Develop a Plan of Care structured document

• [FORMAL PROPOSAL NEEDED] Allow an informant to also be an information system. (Are considering this for author and other roles.)

• [FORMAL PROPOSAL NEEDED: OUT OF SCOPE FOR CDA R3] 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.

• [FORMAL PROPOSAL NEEDED] Review IHE profile for sending lab results in CDA to identify additional CDA R3 requirements. (Consider in light of harmonization Laboratory Result, Release 1.)
• [FORMAL PROPOSAL NEEDED] Provide guidance for image annotations.

• [FORMAL PROPOSAL NEEDED] 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

• [FORMAL PROPOSAL NEEDED] 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

• [FORMAL PROPOSAL NEEDED] Fixed font support for the narrative block

• [FORMAL PROPOSAL NEEDED] 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.

• [FORMAL PROPOSAL NEEDED]

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

• [FORMAL PROPOSAL NEEDED] make explicit that negationInd defaults to false, including in the schema.--GrahameGrieve 08:58, 20 June 2008 (UTC)
• [FORMAL PROPOSAL NEEDED] 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)

• [FORMAL PROPOSAL NEEDED] list APND and RPLC as on allowable combination in the restrictions of relatedDocument typeCode

• [FORMAL PROPOSAL NEEDED] 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 Gary Dickinson Feb 18, 2009: Here are several items for CDAr3 consideration:

[FORMAL PROPOSAL NEEDED] 1) 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).

1a) Non-patient specific documents/records (EHR/IM 3.6.2) 1b) Device/network location (address) of document/record origination or amendment (EHR/IM 3.13) 1c) Access control for document/record origination/amendment (EHR/IM 3.18.2) 1d) Audit entry/trail tracking document/record access/use (EHR/IM 3.19.3) 1e) Audit entry/trail tracking document/record transmittal/disclosure (EHR/IM 3.19.5) 1f) Audit entry/trail tracking document/record receipt (EHR/IM 3.19.6) 1g) Audit entry/trail tracking document/record de-identification or aliasing (EHR/IM 3.19.7) 1h) Audit entry/trail tracking document/record deprecation (EHR/LM 11.11)

[FORMAL PROPOSAL NEEDED] 2) Consent-based document/record access control

[FORMAL PROPOSAL NEEDED] 3) Expansion of confidentiality code - mechanics/specification of control AND applicability at attribute level

• [FORMAL PROPOSAL NEEDED - done] 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

• [FORMAL PROPOSAL NEEDED - done] support multi-language support across different sections with links to the same entries -- Frank Oemig 16 July 2009

• [FORMAL PROPOSAL NEEDED] 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.

• [FORMAL PROPOSAL NEEDED] from Helmut Koenig September 4, 2009: Add order participations for service event(s) to allow for conveying information on referring/ordering physicians.

• [FORMAL PROPOSAL NEEDED] 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.

• [FORMAL PROPOSAL NEEDED] 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.

• [FORMAL PROPOSAL NEEDED] 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.

• [FORMAL PROPOSAL NEEDED] 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.

• [FORMAL PROPOSAL NEEDED] 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.

• [FORMAL PROPOSAL NEEDED] 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.

• [FORMAL PROPOSAL NEEDED] 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.

• [FORMAL PROPOSAL NEEDED] 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)

• [FORMAL PROPOSAL NEEDED] 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

• [FORMAL PROPOSAL NEEDED] 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)

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] Allow multiple race/ethnicity entries. User:Rgeimer - Added as CDA R3 Formal Proposals.

• [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)
  • For formal CDA R3 proposal see: Extend CDA R3 Header with supprt for GP/PCP