|
|
(4 intermediate revisions by the same user not shown) |
Line 4: |
Line 4: |
| [[Category:Template]] | | [[Category:Template]] |
| =Template ''IPSCDAauthor''= | | =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 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== | | ==Actual version== |
| {{:{{BASEPAGENAME}}/dynamic}} | | {{:{{BASEPAGENAME}}/dynamic}} |
| | | |
| ==List of all versions of this template== | | ==List of all versions of this template== |
− | * [[2.16.840.1.113883.10.22.2.2/static-2017-04-11T000000|2017-04-11 (Under develeopment)]] | + | *[[2.16.840.1.113883.10.22.2.2/static-2017-04-11T000000|2017-04-11 (Under pre-publication review)]] |
| + | <!--390a045d57d61e577c54dfcca51f85af7364f6df--> |
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> <!-- template 'IPS CDA Organization' (dynamic) --> </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 |
---|
| | 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> <!-- template 'IPS CDA Organization' (dynamic) --> </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 | <time value="201212290600+0100"/> | | hl7:assignedAuthor
|
| | 1 … 1 | R | | (IPS...hor) | | | @classCode
|
| cs | 0 … 1 | F | ASSIGNED | | | hl7:id
|
| II | 1 … * | R | Author Identifier(s) | (IPS...hor) | | 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 | <code code="221" codeSystem="2.16.840.1.113883.2.9.6.2.7" codeSystemName="ISCO" displayName="Medical doctors"/> | | | 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) | | 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) |
| | url | 0 … 1 | | | | Example | <telecom use="WP" value="tel:+39-051-34343434"/> | | Example | <telecom nullFlavor="NI"/> | Choice | 1 … 1 | | Elements to choose from:- hl7:assignedPerson
- hl7:assignedAuthoringDevice
| | | 0 … 1 | C | | (IPS...hor) | | cs | 0 … 1 | F | PSN | | cs | 0 … 1 | F | INSTANCE | | 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> | | | 1 … * | R | | (IPS...hor) | | | 1 … * | R | | (IPS...hor) | | | | hl7:assignedAuthoringDevice
|
| | 0 … 1 | C | | (IPS...hor) | | Example | <assignedAuthoringDevice classCode="DEV" determinerCode="INSTANCE"> <softwareName displayName="Turriano"/></assignedAuthoringDevice> | Included | | | from 2.16.840.1.113883.10.22.9.2 IPS CDA Device (DYNAMIC) | | cs | 0 … 1 | F | DEV | | cs | 0 … 1 | F | INSTANCE | | CE | 0 … 1 | | | (IPS...hor) | | | | | hl7:manufacturerModelName
|
| SC | 0 … 1 | | | (IPS...hor) | | 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) | | cs | 1 … 1 | F | ORG | | cs | 1 … 1 | F | INSTANCE | | II | 1 … * | R | | (IPS...hor) | | cs | 0 … 1 | | | | ON | 1 … 1 | R | | (IPS...hor) | | cs | 0 … 1 | | | | TEL | 1 … * | R | | (IPS...hor) | | 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) |
| | 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.
| | AD.IPS | 1 … 1 | R | | (IPS...hor) | Included | | | from 2.16.840.1.113883.10.22.11 IPS Address (DYNAMIC) | | 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) |
| | 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 | | | 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 | | | ADXP | 0 … 1 | C | Subject's or Organization's City | (IPS...hor) | | ADXP | 0 … 1 | C | Subject's or Organization's Postal Code | (IPS...hor) | | ADXP | 0 … 1 | C | Subject's or Organization's State or Province | (IPS...hor) | | 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