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

• (needs further discussion to flesh out the requirements before any modeling decisions can be made; there was no formal proposal for this one). [Referred to Charlie regarded Act Ids] 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.
• comment from Grahame: don't know what proposal this was, nor generally what this means

• (needs further discussion to flesh out the requirements before any modeling decisions can be made; there was no formal proposal for this one. see section 1.3.1 in CDA R2). [Grahame] Add a discussion of our approach to defaults (?non normative): only declared for xml attributes, not used at all in choice box.
• proposal regarding substantially increasing section #6 along with discussion of usability concerns

• (look at internationally scoped CDA header template) [Calvin] 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.

• (see also how we changed Medical Records RMIM to clarify the participants off of encompassingEncounter vs. serviceEvent) [Calvin] 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? possible proposal: add author to order, and add "consquential" relationship between service event and order, so that doc mgmt system could index by order and author of order. Also differentiate between header and body

• [Grahame] Per Paul - should not include xsi:schemaLocation in examples.

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

• [Harry] 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)

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

• Allow an informant to also be an information system. (Are considering this for author and other roles.) also really need to clarify the meaning of source of information

• (would presumably need a RIM proposal) [Bob] 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. (bob)

• Make custodian mandatory rather than required User:Rgeimer (We need to revisit the custodian role outside the core usage for exchange of information between providers.)

• clarify how setting a span on a colGroup makes sense --GrahameGrieve 17:13, 12 February 2008 (CST)

• make explicit that negationInd defaults to false (e.g. at the RMIM level), including in the schema.--GrahameGrieve 08:58, 20 June 2008 (UTC). Within Schema, the representation of default values expressed in the RMIM is ITS dependent.

• 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 accreditation, as requested by the American College of Cardiology for imaging lab reports. -- Harry Solomon, 20 January 2009 - we need to figure out how to represent accreditation.

• Add order participations for service event(s) to allow for conveying information on referring/ordering physicians.

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

• 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

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