DECOR-project

General

The project element captures all generic information on the project/domain. It occurs exactly once in a DECOR file

Attributes

@id

required. Static OID for the project. Any project specific identifiers will be assigned under this OID. Examples include dataset concept ids and rules/templates.

Check-circle.svg The project/@id SHOULD be in a well known OID Registry

@prefix

required. Static prefix for the project. Format: 1 to 79 characters and a trailing hyphen, e.g. project-. This is the display name for the @id in many cases. It is used for the naming of various derived artifacts including but not limited to HTML pages and Schematron files. Note: the project prefix MAY match the symbolic name for the project/@id

@defaultLanguage

required. Principal language for the project. Format: ISO 639 alpha 2 (lower case)-ISO-3166 alpha 2 (upper case), e.g. "en-GB" or "en-US". Many elements support multiple languages through an attribute @language. The default language when choices exist will be this language.

Example fragment:

<project id="2.16.840.1.113883.2.4.3.99.999.10" prefix="elga-" defaultLanguage="de-AT">

Elements

name

1..*. Principal name for the project. Format: string without markup. Supports @language, see @defaultLanguage. You are encouraged to keep this name rather short (< 60 characters) as it is used as the title.

Example fragment:

<name language="en-US">Project Name</name>

desc

0..*. Description for the project. Format: string with optional HTML tagging (XHTML). Supports @language, see @defaultLanguage.

Example fragment:

<desc language="en-US">
   <p>This project covers the following topics: 
    <ul>
     <li>Topic 1</li>
     <li>Topic 2</li>
    </ul>
   </p>
</desc>

copyright

1..*. Copyright for the project. Contains references to all organizations/persons that own copyright in some way.

Example fragment:

<copyright years="2008 2009 2010 2011 2012" by="Organization name" logo="ourLogo.jpg">
   <addrLine>5, Middle Road</addrLine>
   <addrLine>Washington, MD 34053</addrLine>
   <addrLine>T +1 70 317 3450</addrLine>
   <addrLine>F +1 70 320 74 37</addrLine>
</copyright>

copyright/@years

required. Enumeration of the years the copyright applies to.

copyright/@by

required. Organization/person that the copyright belongs to

required. Relative path+name of the logo file for the organization/person. Could be a transparent file. Logo file MUST be a web browser supported format, e.g. jpg, gif, or png. The logo file MUST be in a directory named "project/@prefix-logos" that is next to the DECOR file itself. For example, if the project has the prefix peri20 then logos must appear in a directory called peri20-logos.

copyright/addrLine

0..*. Contains address line for reaching the copyright organization/person. Address line is broad concept here. It may hold physical address lines, but also phone, fax, or URL.

author

0..*. Contains a project author. Typically this is a person, rather than an organization.

Example fragment:

<author id="1" username="kaih" email="mailto:user@info.org">dr Kai U. Heitmann</author>

author/@id

required. Sequence number for the author. Note that this sequence number is used in the association of DECOR-issues so sequence numbers SHOULD NOT be reused.

author/@username

optional. User name for the author. This value MAY be used for authorization of the author when he authors the DECOR file through a UI like ART.

author/@email

optional. Email address for this author. This is an optional item. An email address must be preceded by "mailto:".

reference

0..1. Permalink (URL) for the specification. This is primarily used for creating references to the specifications from Schematron messages. If there is no reference element, there will be no @see references in generated Schematron that guide the user to the specification that the particular report or assert is based on.

Example fragment:

<reference url="http://elga.art-decor.org/"/>

restURI

0..* Used to point to services for RESTful retrieval of artifacts inside this specification. Example of these artifacts are value sets. There are two attributes @for that holds the type of artifact, and @format that holds the structure, and the URL for retrieval goes into the text node of the element.

The URI should have placeholders that maybe replaced with actual values of the artifact when retrieving is done:

  • __ID__ - this is replaced by the value of @id of the artifact
  • __ED__ - this is replaced by the value of @effectiveDate of the artifact
  • __PFX__ - this is replaced by the value of @prefix of the project
  • __LANG__ - this is replaced by the desired result language
  • __HC__ - this is replaced by the desired hidecolumns URI parameter

Example fragment for value set retrieval in XML:

<restURI for="VS" format="XML">http://art-decor.org/services/RetrieveValueSet?id=__ID__&amp;effectiveDate=__ED__&amp;format=xml</restURI>

restURI/@for

required. Holds the type of artifact that the URL points to. Possible values are:

artefact code description recommended OID suffix recommended prefix
DS dataset .77.1 projectprefix-dataset-
DE dataset concept .77.2 projectprefix-dataelement-
SC scenario .77.3 projectprefix-scenario-
TR transaction in scenario .77.4 projectprefix-transaction-
CS code system .77.5 projectprefix-codesystem-
IS issue .77.6 projectprefix-issue-
AC actor in scenario .77.7 projectprefix-actor-
CL concept list in dataset .77.8 projectprefix-conceptlist-
EL element in template .77.9 projectprefix-template-element-
TM template .77.10 projectprefix-template-
VS value set .77.11 projectprefix-valueset-
RL rule for instances .77.12 projectprefix-rule-intern-
SX test/example scenario .77.18 projectprefix-test-scenario-
EX test/example instance .77.19 projectprefix-example-instance-
QX qualification test/example .77.20 projectprefix-qualification-test-instance-
CM community .77.21 projectprefix-community-
TX test/example data element .77.22
MP concept map .77.24 projectprefix-map-
QQ questionnaire .77.26
QR questionnaire response .77.27
QE questionnaire (enriched) .77.28

Please note that for the recommended prefix, projectprefix- should be replaced with the actual project/@prefix.

For adding and changing these codes, see ART_Project_Editor#Maintaining_a_local_OID_Registry

restURI/@format

required. The format of the artifact that may be retrieved from the URL. This format is not predefined. Common types are XML (raw retrieval), HTML (pre formatted rendering of the artifact), and CSV (flattened for import in Excel or database)

defaultElementNamespace

0..1. Contains the default namespace prefix that shall mostly be used for dealing with templates in creating Schematrons. If this element is omitted, the default is hl7:. While DECOR is aimed at defining rules for anything in XML, it found its roots in the HL7 community.

Example fragment:

<defaultElementNamespace ns="cda:"/>

buildingBlockRepository

0..*. Carries ART-DECOR building block repository reference(s).

buildingBlockRepository/@url

The required URL to the building block repository. This is an ART-DECOR server with service pack installed and the path part of the URL points typically to the services.

buildingBlockRepository/@ident

The required identification string, used to identify the corresponding repository on the server (in oder to distinguish between multiple repositories).

To use an of define the following statement in your project part of your DECOR project

<buildingBlockRepository url="http://art-decor.org/decor/services/" ident="ad1bbr-"/>

contact

0..*. Contains the primary email address for contact on this specification. This could be a project or program manager, basically address that works for as long as the specification needs to be in effect. The fallback for readers are usually the details of the institutions in the project/copyright section.

The email address is among other places, used as a pointer for issues in the HTML export of the specification.

Example fragment:

<contact email="info@art-decor.org"/>

contact/@email

required. Shall contain the email address

release

0..*. Contains release notes outlining what you did in the specification leading up this point. It has the exact same purpose as the <version/> element but the <release/> element marks a formal publication.

The contents of the <release/> element usually represent a roll up of of the detailed release notes that the reader may find in the <version/> element. So usually the <version/> holds all in depth details, while <release/> is more likely to be at a higher level of abstraction. This is only just practice and nothing in the definition or intent of this element says what or how you need to write.

Example fragment:

<release date="2012-08-01T00:00:00" by="SDO" versionLabel="6.11.0.0">
   <note language="en-US">
       <p>Definitive version for publication based on Dataset version 3.2 with support for:</p>
       <ul>
           <li>Send immunizations</li>
           <li>Query/response immunizations</li>
       </ul>
   </note>
   <note language="nl-NL">
       <p>Definitieve versie ter publicatie op basis van Dataset versie 3.2 met ondersteuning voor:</p>
       <ul>
           <li>Versturen vaccinatiegegevens</li>
           <li>Opvragen/opleveren vaccinatiegegevens</li>
       </ul>
   </note>
</release>

release/note

optional. Contains the actual release note text. Format: string with optional HTML tagging (XHTML). Supports @language, see @defaultLanguage.

release/@by

optional. Holds a reference of max 80 characters to the person or organization that finalized this release.

release/@date

optional. Holds the date/time the release was finalized.

release/@versionLabel

optional. Holds an administrative combined version label that this release is to have. Note that all contained versionable artifacts have versions/effectiveDates of their own. This version label just provides the administrative glue for people to reference this exact bundle of artifacts.

version

0..*. Contains release notes outlining what you did in the specification leading up this point. It has the exact same purpose as the <release/> element but the <version/> element marks a an intermediate publication aimed to discuss with the stakeholders or for Proof-of-concept testing.

The contents of the <version/> element usually represent detailed pointers to specific changes.

Example fragment:

<version date="2012-08-01T00:00:00" by="SDO">
   <desc language="en-US">
       <p>Updated value sets ImmunizationType</p>
       <p>Template element ServiceDeliveryLocation added</p>
   </desc>
   <desc language="nl-NL">
       <p>Waardenlijsten bijgewerkt: ImmunizationType,</p>
       <p>Template element ServiceDeliveryLocation toegevoegd</p>
   </desc>
</version>

version/desc

optional. Contains the actual version release note text. Format: string with optional HTML tagging (XHTML). Supports @language, see @defaultLanguage.

version/@by

optional. Holds a reference of max 80 characters to the person or organization that finalized this version.

version/@date

optional. Holds the date/time the version was finalized.