H&P General Constraints Vs
H&P General Constraints vs. DIR header draft
Item / H&P / DIR / PlanClinicalDocument/templateId / OID only / OID + extension / Will follow SDTC guidelines get an OID-only templateId for this IG. Will not use the H&P general constraints OID, because the constraints won’t match.
Name, Address, Telephone, etc. / Constrained / Unconstrained / Will use H&P constraints unless there is a compelling reason not too.
ClinicalDocument/realmCode / US / UV / Leave as UV
ClinicalDocument/id / UUIDs or OIDs for @root / OIDs only for @root / Checked with Helmut, will keep the OID only constraint. Can provide guidance on using the OID form of UUIDs as a workaround.
ClinicalDocument/title / Shall be present. / Should be present. / Will use the SHALL constraint, and provide guidance to use the LOINC display name if none is present in a transformed report.
ClinicalDocument/setId
ClinicalDocument/versionNumber / Both shall be present or absent / May be present / Will not be present in transformed SR documents.
Can probably use the H&P constraint, then add explanatory text from the old draft.
maritalStatusCode / May be present… / If present, should… / Change to H&P wording.
ClinicalDocument/author / Slight wording differences. Change to H&P wording.
ClinicalDocument/dataEnterer / Slight wording differences. Change to H&P wording.
ClinicalDocument/informant
(also sub types:
Assigned Healthcare Providers
Personal Relations
Unrelated Person
Healthcare Providers) / MAY be present / SHALL NOT be present / Will keep the SHALL NOT constraint for now, but need to state a reason for the prohibition.
ClinicalDocument/custodian / Mentions that it is optional in SR documents, but SHALL be present in CDA, this if missing in SR during a transform, it must be set according to organizational policies. / Will keep DIR wording and guidance.
informationRecipient / When informationRecipient is used, at least one informationRecipient/intendedRecipient/informationRecipient or informationRecipient/intendedRecipient/receivedOrganization SHALL be present / The ClinicalDocument/informationRecipient element MAY be present . This element records the intended recipient of the information at the time the document is created.
The Referring Physician, if present, SHOULD be recorded as an informationRecipient, unless in the local setting another physician (such as the attending physician for an inpatient) is known to be the appropriate recipient of the report .
When no referring physician is present, as in the case of self-referred screening examinations allowed by law, the intendedRecipient MAY be null with a nullFlavor of OTH. The intended recipient MAY also be the health chart of the patient, in which case the receivedOrganization SHALL be the scoping organization of that chart.
When informationRecipient is used, at least one informationRecipient/intendedRecipient/informationRecipient or informationRecipient/intendedRecipient/receievedOrganization SHOULD be present. / Will use the SR constraints for now, but need a reason why the SHALL in the H&P constraints are a SHOULD in DIR. Why would you need an information recipient at all if neither of these are present? Is it just to hold an id?
ClinicalDocument/legalAuthenticator / Slight wording differences. Change to H&P wording.
ClinicalDocument/authenticator / Slightly different constraint wording (not substantive), plus additional descriptive text / Use H&P constraint, but keep the additional descriptive text in prose.
ClinicalDocument/participant / Unconstrained / If present, it is restricted to the referring physician. / Leave the restriction. However, are all other participants intented to be prohibited? The current wording sounds that way.
Also, should the typeCode be restricted to REF?
inFullfilmentOf
documentationOf
authorization / Unconstrained in general constraints (only in specific) / Constrained (too much detail for here). / Will use the DIR constraints. SDTC review in the IG itself.
relatedDocument / Unconstrained / Prohibits replacing a document that has been legally authenticated. / Need to discuss with SDTC. I don’t think any other CDA IG has made this constraint.
componentOf / Unconstrained in general constraints (only in specific) / Unclear if componentOf is required or not.
States that encompassingEncounter/effectiveTime MAY be present, but it is required by CDA, so it has to be be a SHALL / Update the constraint to a SHALL, add guidance on the use of null flavors.
Other issues:
- Use of nullFlavor UNK vs. NI.
- States that a structuredBody SHALL be present, then states “A nonXMLBody element may contain the actual CDA content or may reference it by URL.” However, structuredBody and nonXMLBody are mutually exclusive, this needs to be resolved.
- “A DICOM Object Catalog section SHALL have an empty or absent section/text element.”. Since we generally require section/text to be present, I think this prohibition should be removed, and rather it should state that the DICOM object catalog SHALL include section/text, and that it may be rendered as a series of hyperlinks, or something to that effect.