Latest revision as of 05:11, 3 April 2024

Comments on this page

Template IPSCDAauthor

A CDA document shall have at least one author. Authors could be either human (ClinicalDocument/author/assignedAuthor/assignedPerson) either devices (ClinicalDocument/author/assignedAuthor/assignedAuthoringDevice).For definition “The author element represents the creator of the clinical document. If the role of the actor is the entry of information from his or her own knowledge or application of skills, that actor is the author. If one actor provides information to another actor who filters, reasons, or algorithmically creates new information, then that second actor is also an author, having created information from his or her own knowledge or skills.” [From Implementation Guide for CDA Release 2: Imaging Integration – UV Realm, March 2009].According to this definition, not any device that generates the electronic document has to be considered as an author:a spider collecting and filtering information from different repositories, according to defined rules and policies, for the scope of creating a Patient Summary is definitely a document author (and in some cases the only one );an application that transforms a Patient Summary record into this CDA format may not be an author;For cross-border exchange purposes, a device, which modifies the concepts conveyed (e.g. applying code system mappings), should appear as one of the authors. In this case (document generated through a transformation process) the authors of the parent (original) patient summary should appear as authors as well.Further to this, authorship can give information about the nature of Patient Summary :if there is a person author only, then the Patient Summary is the result of a practitioner clinical act;if there are device authors only, the summary was automatically generated according to well defined rules defined by the responsible organization.The CDA standard allows to provide detailed information about what was authored by whom in the Patient Summary, allowing the specification of authorship at the whole document level, at the section level and also at the entry level. In any case it is not required to repeat this information for each of the mentioned levels, taking advantage of the context conduction propriety. In fact “context that is specified on an outer tag holds true for all nested tags, unless overridden on a nested tag. Context specified on a tag within the CDA body always overrides context propagated from an outer tag. For instance, the specification of authorship at a document section level overrides all authorship propagated from outer tags.” (HL7 CDA R2 Standard).

Actual version

Id

2.16.840.1.113883.10.22.2.2

Effective Date

2017‑04‑11

Status

Under pre-publication review

Version Label

STU1

Name

IPSCDAauthor

Display Name

IPS CDA author

Description

A CDA document shall have at least one author. Authors could be either human (ClinicalDocument/author/assignedAuthor/assignedPerson) either devices (ClinicalDocument/author/assignedAuthor/assignedAuthoringDevice).

For definition “The author element represents the creator of the clinical document. If the role of the actor is the entry of information from his or her own knowledge or application of skills, that actor is the author. If one actor provides information to another actor who filters, reasons, or algorithmically creates new information, then that second actor is also an author, having created information from his or her own knowledge or skills.” [From Implementation Guide for CDA Release 2: Imaging Integration – UV Realm, March 2009].

According to this definition, not any device that generates the electronic document has to be considered as an author:

a spider collecting and filtering information from different repositories, according to defined rules and policies, for the scope of creating a Patient Summary is definitely a document author (and in some cases the only one );
an application that transforms a Patient Summary record into this CDA format may not be an author;
For cross-border exchange purposes, a device, which modifies the concepts conveyed (e.g. applying code system mappings), should appear as one of the authors. In this case (document generated through a transformation process) the authors of the parent (original) patient summary should appear as authors as well.

Further to this, authorship can give information about the nature of Patient Summary :

if there is a person author only, then the Patient Summary is the result of a practitioner clinical act;
if there are device authors only, the summary was automatically generated according to well defined rules defined by the responsible organization.

The CDA standard allows to provide detailed information about what was authored by whom in the Patient Summary, allowing the specification of authorship at the whole document level, at the section level and also at the entry level. In any case it is not required to repeat this information for each of the mentioned levels, taking advantage of the context conduction propriety.
In fact “context that is specified on an outer tag holds true for all nested tags, unless overridden on a nested tag. Context specified on a tag within the CDA body always overrides context propagated from an outer tag. For instance, the specification of authorship at a document section level overrides all authorship propagated from outer tags.” (HL7 CDA R2 Standard).

Classification

CDA Header Level Template

Open/Closed

Open (other than defined elements are allowed)

Uses

Uses 2 templates

Uses	as	Name	Version
2.16.840.1.113883.10.22.9.2	Include	IPS CDA Device (STU1)	DYNAMIC
2.16.840.1.113883.10.22.9.1	Include	IPS CDA Organization (STU1)	DYNAMIC

Relationship

Adaptation: template 2.16.840.1.113883.10.12.102 CDA author (2005‑09‑07)

ref

ad1bbr-

Example

Human Author

<author>
  <time value="201212290600+0100"/>  <assignedAuthor>
    <id root="2.16.840.1.113883.2.9.4.3.2" extension="RSSMRA00A01F205F" assigningAuthorityName="Ministero Economia e Finanze"/>    <code code="221" codeSystem="2.16.840.1.113883.2.9.6.2.7" codeSystemName="ISCO" displayName="Medico"/>    <addr use="WP">
      <streetAddressLine>Viale della Cristallina 3</streetAddressLine>      <city>Bologna</city>      <state>BO</state>      <postalCode>40121</postalCode>      <country>IT</country>    </addr>    <telecom use="WP" value="tel:+39-051-34343434"/>    <assignedPerson>
      <name>
        <given>Paolo</given>        <family>Rossi</family>      </name>    </assignedPerson>    <representedOrganization>
      
    </representedOrganization>  </assignedAuthor></author>

Example

Device Author

<author>
  <time value="201212290600+0100"/>  <assignedAuthor>
    <id root="1.2.3.999" extension="__example only__"/>    <addr use="WP">
      <state>Castilla-La Mancha</state>      <city>Toledo</city>      <precinct>Toledo</precinct>      <country>ES</country>      <postalCode>45071</postalCode>      <streetAddressLine>Av. Río Guadiana, 4</streetAddressLine>    </addr>    <telecom nullFlavor="NI"/>    <assignedAuthoringDevice classCode="DEV" determinerCode="INSTANCE">
      <softwareName displayName="Turriano"/>    </assignedAuthoringDevice>    <representedOrganization classCode="ORG" determinerCode="INSTANCE">
      <id root="1.2.3.999" extension="__example only__"/>      <name>SESCAM</name>      <telecom use="WP" value="tel:+34925274100"/>      <addr use="WP">
        <state>Castilla-La Mancha</state>        <city>Toledo</city>        <precinct>Toledo</precinct>        <country>ES</country>        <postalCode>45071</postalCode>        <streetAddressLine>Av. Río Guadiana, 4</streetAddressLine>      </addr>    </representedOrganization>  </assignedAuthor></author>

Item

DT

Card

Conf

Description

Label

hl7:author

1 … *

R

(IPS...hor)

@typeCode

cs

0 … 1

F

AUT

@contextControlCode

cs

0 … 1

F

OP

Example

<author>
  <time value="201212290600+0100"/>  <assignedAuthor>
    <id root="2.16.840.1.113883.2.9.4.3.2" extension="RSSMRA00A01F205F" assigningAuthorityName="Ministero Economia e Finanze"/>    <addr use="WP">
      <streetAddressLine>Viale della Cristallina 3</streetAddressLine>      <city>Bologna</city>      <state>BO</state>      <postalCode>40121</postalCode>      <country>IT</country>    </addr>    <telecom use="WP" value="tel:+39-051-34343434"/>    <assignedPerson>
      <name>
        <given>Paolo</given>        <family>Rossi</family>      </name>    </assignedPerson>  </assignedAuthor>  <representedOrganization>
    
  </representedOrganization></author>

hl7:functionCode

CE.IPS

0 … 1

R

(IPS...hor)

hl7:time

TS.IPS.TZ

1 … 1

R

The author/time element represents the start time of the author’s participation in the creation of the clinical document.

(IPS...hor)

Example

hl7:assignedAuthor

1 … 1

R

(IPS...hor)

@classCode

cs

0 … 1

F

ASSIGNED

hl7:id

II

1 … *

R

Author Identifier(s)

(IPS...hor)

@nullFlavor

cs

0 … 1

hl7:code

CE.IPS (extensible)

0 … 1

R

A code, which identifies the profession/competence/specialty of the author when it is a person.

(IPS...hor)

CONF

The value of @code should be drawn from value set 2.16.840.1.113883.11.22.53 IPS Healthcare Professional Roles (DYNAMIC)

Example

hl7:addr

AD.IPS

1 … *

R

(IPS...hor)

Example

<addr use="WP">
<streetAddressLine>Viale della Cristallina 3</streetAddressLine> <city>Bologna</city> <state>BO</state> <postalCode>40121</postalCode> <country>IT</country></addr>

hl7:telecom

TEL.IPS

1 … *

R

(IPS...hor)

@use

set_cs

0 … 1

CONF

The value of @use shall be drawn from value set 2.16.840.1.113883.1.11.201 TelecommunicationAddressUse (DYNAMIC)

@value

url

0 … 1

Example

Example

Choice

1 … 1

Elements to choose from:

hl7:assignedPerson
hl7:assignedAuthoringDevice

hl7:assignedPerson

0 … 1

C

(IPS...hor)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … *

R

Name of the person (e.g. the Healthcare Professional) authoring this document

(IPS...hor)

Example

<name>
<given>John</given> <family>Español Smith</family></name>

hl7:family

1 … *

R

(IPS...hor)

hl7:given

1 … *

R

(IPS...hor)

hl7:assignedAuthoringDevice

0 … 1

C

(IPS...hor)

Example

Included

from 2.16.840.1.113883.10.22.9.2 IPS CDA Device (DYNAMIC)

@classCode

cs

0 … 1

F

DEV

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:code

CE

0 … 1

(IPS...hor)

hl7:manufacturerModelName

SC

0 … 1

(IPS...hor)

hl7:softwareName

SC

0 … 1

(IPS...hor)

hl7:representedOrganization

0 … 1

R

(IPS...hor)

Included

from 2.16.840.1.113883.10.22.9.1 IPS CDA Organization (DYNAMIC)

@classCode

cs

1 … 1

F

ORG

@determinerCode

cs

1 … 1

F

INSTANCE

hl7:id

II

1 … *

R

(IPS...hor)

@nullFlavor

cs

0 … 1

hl7:name

ON

1 … 1

R

(IPS...hor)

@nullFlavor

cs

0 … 1

hl7:telecom

TEL

1 … *

R

(IPS...hor)

@use

set_cs

1 … 1

R

CONF

The value of @use shall be drawn from value set 2.16.840.1.113883.1.11.201 TelecommunicationAddressUse (DYNAMIC)

@nullFlavor

cs

0 … 1

Constraint

If there is no information, the nullFlavor attribute shall have a value of 'NI' and the "value" and "use" attributes shall be omitted, otherwise the nullFlavor attribute shall not be present, and the "value" and "use" attributes shall be present.

hl7:addr

AD.IPS

1 … 1

R

(IPS...hor)

Included

from 2.16.840.1.113883.10.22.11 IPS Address (DYNAMIC)

@use

set_cs

0 … 1

CONF

The value of @use shall be drawn from value set 2.16.840.1.113883.1.11.10637 PostalAddressUse (2005‑05‑01)

@nullFlavor

cs

0 … 1

F

NI

Constraint

SHALL NOT have mixed content except for white space
If there is no information, the nullFlavor attribute shall have a value of 'NI' and no address parts shall be present, otherwise there shall be no nullFlavor attribute, and at least one of the address parts listed below shall be present.

Schematron assert

role

error

test

@nullFlavor or hl7:*

Message

If addr is not nullflavored at least one sub element has to be provided

hl7:streetAddressLine

ADXP

0 … *

C

Subject's or Organization's Street Address Line

(IPS...hor)

Schematron assert

role

error

test

hl7:streetAddressLine and (hl7:city or hl7:postalCode)

Message

If the address line is included either the city or the zip code has to be provided

hl7:city

ADXP

0 … 1

C

Subject's or Organization's City

(IPS...hor)

hl7:postalCode

ADXP

0 … 1

C

Subject's or Organization's Postal Code

(IPS...hor)

hl7:state

ADXP

0 … 1

C

Subject's or Organization's State or Province

(IPS...hor)

hl7:country

ADXP

0 … 1

C

Subject's Country.

(IPS...hor)

Constraint

The content of this element SHALL be selected EITHER from ValueSet ISO Country Alpha-2 urn:oid:2.16.840.1.113883.1.11.20300 DYNAMIC OR MAY be selected from ISO Country Alpha-3 2.16.840.1.113883.1.11.171 DYNAMIC, IF the country is not specified in ValueSet ISO Country Alpha-2 urn:oid:2.16.840.1.113883.1.11.20300.

List of all versions of this template

2017-04-11 (Under pre-publication review)

@@ Line 5: / Line 5: @@
 =Template ''IPSCDAauthor''=
-<p>A CDA document shall have at least one author. Authors could be either human (ClinicalDocument/author/assignedAuthor/assignedPerson) either devices (ClinicalDocument/author/assignedAuthor/assignedAuthoringDevice).For definition “The author element represents the creator of the clinical document. If the role of the actor is the entry of information from his or her own knowledge or application of skills, that actor is the author. If one actor provides information to another actor who filters, reasons, or algorithmically creates new information, then that second actor is also an author, having created information from his or her own knowledge or skills.” [From Implementation Guide for CDA Release 2: Imaging Integration – UV Realm, March 2009].According to this definition, not any device that generates the electronic document has to be considered as an author:a spider collecting and filtering information from different repositories, according to defined rules and policies, for the scope of creating a Patient Summary is definitely a document author (and in some cases the only one );an application that transforms a Patient Summary record into this CDA format may not be an author;For cross-border exchange purposes, a device, which modifies the concepts conveyed (e.g. applying code system mappings), should appear as one of the authors. In this case (document generated through a transformation process) the authors of the parent (original) patient summary should appear as authors as well.Further to this, authorship can give information about the nature of Patient Summary :if there is a person author only, then the Patient Summary is the result of a practitioner clinical act;if there are device authors only, the summary was automatically generated according to well defined rules defined by the responsible organization.The CDA standard allows to provide detailed information about what was authored by whom in the Patient Summary, allowing the specification of authorship at the whole document level, at the section level and also at the entry level. In any case it is not required to repeat this information for each of the mentioned levels, taking advantage of the context conduction propriety. In fact “context that is specified on an outer tag holds true for all nested tags, unless overridden on a nested tag. Context specified on a tag within the CDA body always overrides
+<p>A CDA document shall have at least one author. Authors could be either human (ClinicalDocument/author/assignedAuthor/assignedPerson) either devices (ClinicalDocument/author/assignedAuthor/assignedAuthoringDevice).For definition “The author element represents the creator of the clinical document. If the role of the actor is the entry of information
-      context propagated from an outer tag. For instance, the specification of authorship at a document section level overrides all authorship propagated from outer tags.” (HL7 CDA R2 Standard).</p>
+                        from his or her own knowledge or application of skills, that actor is the author. If one actor provides information to another actor who filters, reasons, or algorithmically creates new information, then that second actor is also an author, having created information from his or her own knowledge or skills.” [From Implementation Guide for CDA
+                    Release 2: Imaging Integration – UV Realm, March 2009].According to this definition, not any device that generates the electronic document has to be considered as an author:a spider collecting and filtering information from different repositories, according to defined rules and policies, for the scope of creating a Patient Summary is definitely a document
+                        author (and in some cases the only one );an application that transforms a Patient Summary record into this CDA format may not be an author;For cross-border exchange purposes, a device, which modifies the concepts conveyed (e.g. applying code system mappings), should appear as one of the authors. In this case (document generated through a transformation
+                        process) the authors of the parent (original) patient summary should appear as authors as well.Further to this, authorship can give information about the nature of Patient Summary :if there is a person author only, then the Patient Summary is the result of a practitioner clinical act;if there are device authors only, the summary was
+                        automatically generated according to well defined rules defined by the responsible organization.The CDA standard allows to provide detailed information about what was authored by whom in the Patient Summary, allowing the specification of authorship at the whole document level, at the section level and also at the entry level. In any case it is not required to
+                repeat this information for each of the mentioned levels, taking advantage of the context conduction propriety. In fact “context that is specified on an outer tag holds true for all nested tags, unless overridden on a nested tag. Context specified on a tag within the CDA body always overrides context propagated from an outer tag. For instance, the specification of
+                authorship at a document section level overrides all authorship propagated from outer tags.” (HL7 CDA R2 Standard).</p>
 ==Actual version==
 {{:{{BASEPAGENAME}}/dynamic}}
@@ Line 12: / Line 18: @@
 ==List of all versions of this template==
 *[[2.16.840.1.113883.10.22.2.2/static-2017-04-11T000000|2017-04-11 (Under pre-publication review)]]
-<!--db5419b77f93b32a000feb631cc81d92c40d98d1-->
+<!--390a045d57d61e577c54dfcca51f85af7364f6df-->

Difference between revisions of "2.16.840.1.113883.10.22.2.2"

Latest revision as of 05:11, 3 April 2024

Template IPSCDAauthor

Actual version

List of all versions of this template

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Navigation

Tools

Hot Pages