In the cross enterprise document sharing family of IHE profiles, one of the metadata attributes associated with a document is formatCode. When XDS was created, we felt we needed a way to distinguish between content based on the set of business rules it adhered to. This is more than just mime-type or schema. It's closely related to CDA's templateId element or FHIR's profile tag.
As part of an affinity domains configuration, the governors of that domain can specify what formatCode values should be used for submitted documents, and when.
Recently a representative of a national program asked me: Should we create our own format codes or use IHE format codes, noting that his national program had added rules to IHE profiles for which IHE had already created formatCodes.
The answer to that question is "Yes", or more accurately, "it depends."
Within your affinity domain (for which you set the policies), will you have cases where distinguishing between documents using IHE format codes and your own additional requirements is necessary? If so, create your own format codes for these documents. Otherwise, simply add the requirement to your domain policy that all documents must meet national requirements as well as adhere to IHE templates, and stick with the IHE formatCodes (as it is both simpler, and will require less effort on behalf of developers who already know how to use those).
Creating your own format codes, even when others already exist is perfectly legitimate. Format codes are a way to express a concept that is needed to manage an affinity domain. If what is there doesn't let you manage the domain, then there's nothing that says you cannot apply your own set. However, if you are smart, you will do your best to stick with what already exists when you can, and ONLY when it doesn't let you do what you need, will you do something different.
Keith
As part of an affinity domains configuration, the governors of that domain can specify what formatCode values should be used for submitted documents, and when.
Recently a representative of a national program asked me: Should we create our own format codes or use IHE format codes, noting that his national program had added rules to IHE profiles for which IHE had already created formatCodes.
The answer to that question is "Yes", or more accurately, "it depends."
Within your affinity domain (for which you set the policies), will you have cases where distinguishing between documents using IHE format codes and your own additional requirements is necessary? If so, create your own format codes for these documents. Otherwise, simply add the requirement to your domain policy that all documents must meet national requirements as well as adhere to IHE templates, and stick with the IHE formatCodes (as it is both simpler, and will require less effort on behalf of developers who already know how to use those).
Creating your own format codes, even when others already exist is perfectly legitimate. Format codes are a way to express a concept that is needed to manage an affinity domain. If what is there doesn't let you manage the domain, then there's nothing that says you cannot apply your own set. However, if you are smart, you will do your best to stick with what already exists when you can, and ONLY when it doesn't let you do what you need, will you do something different.
Keith
Well, I asked if within the CDA another templateID could be used to identify that the CDA was created from a specific version of software. Recognizing that software can have bugs that result in buggy encoding that would eventually get corrected. Thus it might be interesting to a consuming system to know if the CDA was created by the known buggy version of software or the software that does not yet have known bugs. The templateID is a multiple value concept, so extra values should not be an issue.
ReplyDeleteWhere as FormatCode is a single valued element. Thus FormatCode must represent the highest and most broadly understood format. The FormatCode would likely need to be that for C-CDA R2.1; since that would be the highest of the broadly known FormatCode, where as an additional TemplateID would add further refinements by the software-version/service/organization.