Skip to end of metadata
Go to start of metadata

Development

Extensions are developed during implementation guide development or other workgroup activity. Before Structured Documents will approve an extension, it must be listed on the CDA Extensions page and conform to the rules listed therein. Leave the Approved on and Implemented on columns blank. Submit the extension for approval during a weekly workgroup call or during an HL7 working group meeting. Once the committee approves the extension, populate the approval date and include a link to the meeting notes containing the approval vote.

Implementation

The extension schema lives at https://github.com/HL7/cda-core-2.0/tree/master/schema/extensions/SDTC. Implementers may either crate a new branch (if they have access to the HL7 Github) or fork the cda-core-2.0 repository. Make the changes and verify the extension validates an instance of a CDA document containing that extension as appropriate. 

Additionally, new extensions should be incorporated into the FHIR logical model by modifying the affected schema's StructureDefinition in https://github.com/HL7/cda-core-2.0/tree/master/input/resources.

At no time should the https://github.com/HL7/cda-core-2.0/tree/master/schema/normative ever be edited during this process. This directory contains the original approved published normative version of the CDA schema.

Once the schema and FHIR model have been updated and tested, create a PR against https://github.com/HL7/cda-core-2.0 with proposed changes to the schema. This PR should include a link to the CDA Extensions page and include an example of the extension in use.

Email the Structured Documents listserv and co-chairs with the PR for review. Once the review period is over (1 week, or whatever the reviewers indicated as needed), request the co-chairs add an approval agenda topic during the next conference call.

Release

Once the PR is merged, create a new release at https://github.com/HL7/cda-core-2.0/releases. Follow the convention set forth by previous releases (tag version, release title, and description). As part of the release, create a ZIP file of the SDTC folder, named according to the date of release, and include it in the release. Save the release as a draft and open the Assets list to get the URL of the uploaded ZIP file. Edit the release and include a link to this ZIP as part of the description, so implementers can easily access the extensions schema part of the release.

Once the release is published, populate the Implemented on column on the CDA Extensions page, and link the date to the GitHub release (see alternateIdentification as an example).

  • No labels