CDA R3 Workplan Items

These are CDA Suggested Enhancements that the SD committee has accepted as part of the CDA R3 workplan.

Current status: Each of these items needs to be assigned to a SAEAF category. (Austin to do). Also, identify the items that relate to the bake-off. (Austin)

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

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

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

• In the case of multiple preconditions, are they to be AND'd or OR'd?

• Review general header constraints template (template published with H&P, and used in other IGs - should these constraints roll into CDA R3)

• 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 entryRelationship.priorityNumber

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

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

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

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

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

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

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

• (to be addressed as part of model bake off) 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 support for GOL/RSK and GOAL/RISK to the entries. User:Kboone (Will be addressed through adoption of Clinical Statement &/or the RIM)

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

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

• ParentDocument.code should be changed from CD to CE - note: make them consistent

• 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 nonXMLBody/id

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

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

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

• For all vocabulary, list the Concept Domain, coding strength, OIDs, Value Set, static/dynamic, etc.

• All enumerated CNE domains should be x-domains (value sets) - eg. OrganizationPartOf.statusCode