The CDA-CH-VACD content profile is a Swiss realm of the IHE Immunization Content profile. It is available at eHealth Suisse.
The serialization and deserialization of CDA-CH-VACD is supported by the eHealth Connector. The CDA-CH-VACD content profile describes typical scenarios which make use of slightly different instances of the CDA document:
immunization certification document containing all known vaccinations of a patient
a request for clinical guidance for immunization recommendations and
the according answer of a clinical decision support system
documentation of an immunization administration (vaccination), which has been applied to the patient
These document types are supported by the eHealthConnector CDA-CH-VACD implementation.
The analysis of the Demo Applications is recommended for getting started.
Use the DemoVACD demo for the current use case. It will generate example document instances and save them in a temp path.
There exist also some HL7 FHIR resources that can be used to demonstrate the functionality. If you provide path and filename to DemoVACD, it will generate appropriate CDA documents. The FHIR resources can be found in rsc\demoCdaChVacd.
If you are an application programmer and want to see, how the API is used to generate CDA-CH-VACD documents, take a look inside the java or dotnet demo project. The methods “org.ehealth_connector.demo.cda.DemoVACD.doDemo()” (java demo application) and “eHealthConnectorDemo.MainForm.btnCDACHDemo_Click()” (dotnet demo application) are good starting points.
Updates with R201510 for the CDA-CH-VACD content profile (16.9.2015):
updated MDHT model org.openhealthtools.mdht.uml.cda.ch.model
new entries MedicationTargetEntry (18.104.22.168), CriterionEntry (22.214.171.124), PreconditionEntry implied from CriterionEntry
adjusting model entry Immunization: medicalTarget reference: entryRelationship to MedicationTargetEntry, precondition reference to Precondition Element
adjusting model entry ImmunizationRecommondation: medicalTarget reference: entryRelationship to MedicationTargetEntry, precondition reference to Precondition Element, relationship externalDocument
please note the following MDHT modeling limitations in relation to the eHealth Connector:
template extensions can not be provided in modeling (necessary for swiss templates), do not add the swiss root template id more than once, otherwise the classes will not automatically deserialize
vocabulary specified in modeling classes don’t generate the relevant code
validating logic of mdht is not used in ehealth connector
adding a dependent relationship in the model does not add boiler code in code generation
Convenience API extension
new Facade class for base MDHT functionality, MdhtFacade (MdhtFacade constructor and accessors to mdth are protected, no public mdht classes exposed which decouples a convenience api user from the mdht dependency).Templates implementing MdhtFacade specify MDHT Template and getter/setters as the convenience API
new convenience classes for corresponding MDHT entries (org.ehealth_connector.cda.MedicationTargetEntry, org.ehealth_connector.cda.CriterionEntry, org.ehealth_connector.cda.ProblemEntry, org.ehealth_connector.cda.CommentEntry, ImmunizationSection)
test classes for the new conveniences classes, unit tests which check template implementations (via DOM/XPaths)