Difference between revisions of "2.16.840.1.113883.10.22.2.7"

From HL7 IPS
Jump to: navigation, search
(Automated ADBot page content)
(Automatic ADBot page (5b8b79e8d447ad1be1b016276ad19143ade88547))
 
(5 intermediate revisions by the same user not shown)
Line 4: Line 4:
 
[[Category:Template]]
 
[[Category:Template]]
 
=Template ''IPSCDArelatedDocument''=
 
=Template ''IPSCDArelatedDocument''=
 +
 +
<p>
 +
                An IPS may have three types of parent document:
 +
               
 +
                    A superseded version that the present instance of the document wholly replaces (typeCode = RPLC). 
 +
                    A source document from which the present document is transformed (typeCode = XFRM). An IPS may be created by transformation from an already existing local Patient Summary or an IPS document. An example of this case is the creation of a derived instance in which translations are appended in order to facilitate the cross-border usage of this document; or the case in which a
 +
                        local patient summary is transformed to originate a new IPS instance.
 +
                    An original version that the present document integrates (typeCode = APND). Some cross-border legal agreements (e.g.  the European Digital Service Infrastructure for eHealth) require the patient summary to be accompanied by  a printable representation of the original national data / document this IPS comes from. The relationship between the IPS and this content may be
 +
                        tracked using this relationship. 
 +
               
 +
                Note 1: even for countries not dealing with real documents in their National Infrastructures (e.g. data collected from local databases), this mechanism could be useful to identify the collection of data used for generating the epSOS CDAs, facilitating the information backtracking. In that case the ID might be that of the epSOS friendly document or of any other kind of
 +
                    intermediate document used for generating the NCP document input. Note 2: even if none of the allowable relationships defined by the CDA standard (XFRM, RPLC, APND) fits perfectly with the described case; the APND relationship seems to be the one that fits the better. In fact “An addendum is a separate document that references the parent document, and may
 +
                    extend or alter the observations in the prior document. The parent document remains a current component of the patient record, and the addendum and its parent are both read by report recipients.”
 +
            </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.7/static-2017-04-12T000000|2017-04-12 (Under develeopment)]]
+
*[[2.16.840.1.113883.10.22.2.7/static-2017-04-12T000000|2017-04-12 (Under pre-publication review)]]
 +
<!--06db5d3b41e69939e0e690f6fec5c8d3ad325ddd-->

Latest revision as of 05:11, 13 June 2024

Comments on this page

Template IPSCDArelatedDocument

An IPS may have three types of parent document: A superseded version that the present instance of the document wholly replaces (typeCode = RPLC).  A source document from which the present document is transformed (typeCode = XFRM). An IPS may be created by transformation from an already existing local Patient Summary or an IPS document. An example of this case is the creation of a derived instance in which translations are appended in order to facilitate the cross-border usage of this document; or the case in which a local patient summary is transformed to originate a new IPS instance. An original version that the present document integrates (typeCode = APND). Some cross-border legal agreements (e.g.  the European Digital Service Infrastructure for eHealth) require the patient summary to be accompanied by  a printable representation of the original national data / document this IPS comes from. The relationship between the IPS and this content may be tracked using this relationship.  Note 1: even for countries not dealing with real documents in their National Infrastructures (e.g. data collected from local databases), this mechanism could be useful to identify the collection of data used for generating the epSOS CDAs, facilitating the information backtracking. In that case the ID might be that of the epSOS friendly document or of any other kind of intermediate document used for generating the NCP document input. Note 2: even if none of the allowable relationships defined by the CDA standard (XFRM, RPLC, APND) fits perfectly with the described case; the APND relationship seems to be the one that fits the better. In fact “An addendum is a separate document that references the parent document, and may extend or alter the observations in the prior document. The parent document remains a current component of the patient record, and the addendum and its parent are both read by report recipients.”

Actual version

Id2.16.840.1.113883.10.22.2.7Effective Date2017‑04‑12
StatusKorange.png Under pre-publication reviewVersion LabelSTU1
NameIPSCDArelatedDocumentDisplay NameIPS CDA relatedDocument
Description

An IPS may have three types of parent document:

  • A superseded version that the present instance of the document wholly replaces (typeCode = RPLC). 
  • A source document from which the present document is transformed (typeCode = XFRM). An IPS may be created by transformation from an already existing local Patient Summary or an IPS document. An example of this case is the creation of a derived instance in which translations are appended in order to facilitate the cross-border usage of this document; or the case in which a local patient summary is transformed to originate a new IPS instance.
  • An original version that the present document integrates (typeCode = APND). Some cross-border legal agreements (e.g.  the European Digital Service Infrastructure for eHealth) require the patient summary to be accompanied by  a printable representation of the original national data / document this IPS comes from. The relationship between the IPS and this content may be tracked using this relationship. 

Note 1: even for countries not dealing with real documents in their National Infrastructures (e.g. data collected from local databases), this mechanism could be useful to identify the collection of data used for generating the epSOS CDAs, facilitating the information backtracking. In that case the ID might be that of the epSOS friendly document or of any other kind of intermediate document used for generating the NCP document input.
Note 2: even if none of the allowable relationships defined by the CDA standard (XFRM, RPLC, APND) fits perfectly with the described case; the APND relationship seems to be the one that fits the better. In fact “An addendum is a separate document that references the parent document, and may extend or alter the observations in the prior document. The parent document remains a current component of the patient record, and the addendum and its parent are both read by report recipients.”

ClassificationCDA Header Level Template
Open/ClosedOpen (other than defined elements are allowed)
RelationshipAdaptation: template 2.16.840.1.113883.10.12.111 CDA relatedDocument (2005‑09‑07)
ref
ad1bbr-
Example
Example of national document identified by its ID
<relatedDocument typeCode="XFRM">
  <!-- the IPS is obtained as trasformation of the "aa-bb-cc" document -->
  <parentDocument>
    <id root="aa-bb-cc"/>  </parentDocument>
</relatedDocument>
Example
Reference to the local PS and to supporting documentation
<!-- the example starts here -->
<relatedDocument typeCode="XFRM">
  <!-- the IPS is obtained as trasformation of the "aa-bb-cc" Local Patient Summary -->
  <parentDocument>
    <id root="aa-bb-cc"/>  </parentDocument>
</relatedDocument>
<relatedDocument typeCode="APND">
  <!-- the IPS is integrated by the information provided by the "aa1-bb1-cc1" document -->
  <parentDocument>
    <id root="aa1-bb1-cc1"/>  </parentDocument>
</relatedDocument>
<!-- the example ends here -->
ItemDTCardConfDescriptionLabel
hl7:relatedDocument
0 … *R(IPS...ent)
Treetree.png@typeCode
cs1 … 1R
 CONF
The value of @typeCode shall be drawn from value set 2.16.840.1.113883.1.11.11610 x_ActRelationshipDocument (DYNAMIC)
Treetree.pnghl7:parentDocument
1 … 1R(IPS...ent)
Treeblank.pngTreetree.png@classCode
cs0 … 1FDOCCLIN
Treeblank.pngTreetree.png@moodCode
cs0 … 1FEVN
Treeblank.pngTreetree.pnghl7:id
II1 … *R(IPS...ent)
Treeblank.pngTreetree.pnghl7:code
CD.IPS0 … 1R(IPS...ent)
Treeblank.pngTreeblank.pngTreetree.png@codeSystem
CONF0 … 1F2.16.840.1.113883.6.1 (LOINC)
Treeblank.pngTreetree.pnghl7:text
ED0 … 1R(IPS...ent)
Treeblank.pngTreetree.pnghl7:setId
II0 … 1R(IPS...ent)
Treeblank.pngTreetree.pnghl7:versionNumber
INT0 … 1R(IPS...ent)


List of all versions of this template