This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Order interaction for the creation of a document"

From HL7Wiki
Jump to navigation Jump to search
Line 1: Line 1:
 
==Summary==
 
==Summary==
This proposal documents a new set of HL7 version 3 interactions related to 'ordering the creation of a document'. The newly created set of interactions should be part of a new Topic in the RCMR (medical records) domain. The medical records domain is the responsability of the [[Structured Documents WG]].
+
This proposal documents a new set of HL7 version 3 interactions related to 'ordering the creation of a document'. The document could be of any mime-type, and could have a structured or a non-structured content. The focus will be on structured CDA (and more general: SDA) documents, but this should not preclude the interactions from being used for other documents.
 +
 
 +
The newly created set of interactions may become part of a new Topic in the RCMR (medical records) domain. The medical records domain is the responsability of the [[Structured Documents WG]].
  
 
==Use-case==
 
==Use-case==
Line 13: Line 15:
 
Requirements related to the static model:
 
Requirements related to the static model:
 
*The basic model (refined by further discussions) could be defined to be the [[CDA Header]] model, with the focal DOCCLIN Act in RQO mood.
 
*The basic model (refined by further discussions) could be defined to be the [[CDA Header]] model, with the focal DOCCLIN Act in RQO mood.
*The final model should be in compliance with the [[Composite Order]] model (as defined by the Orders and Observations WG).
+
*The final model should be in compliance with the [[Composite Order]] model (as defined by the Orders and Observations WG). The current Compsite Order model may have to be updated to support the ordering of documents.
 +
 
 +
{| class="prettytable" width="100%" border="1"
 +
|- style="background-color:#AFEEEE; text-align:left;"
 +
! Grouping !! Request item !! Notes
 +
|-
 +
| Structure || Document.code || The requested document type
 +
|-
 +
| Structure || Document.templateID || Set of template IDs the document creator is requested to adhere to (only applicable for structured documents)
 +
|-
 +
| Structure || Document.profileId || The ProfileID (the implementation guide) the document creator is requested to adhere to (only applicable for structured documents)
 +
|-
 +
| Structure || Document.mimeType || The mime type the document creator is requested to create (if equal to application/hl7-v3-sda templateIds will have to be used to identify CDA R2, CDA R3, SPL, etc.)
 +
|-
 +
| Subject || Activities.effectiveTime || An interval of time for the data which should be reported on/documented
 +
|-
 +
| Subject || Encounter.id || The encounter.ID of the encounter which should be reported on/documented
 +
|-
 +
| Subject || MainActivity.id || Identifier of the main (focal) requested/performed act
 +
|-
 +
| Subject || MainActivity.status || Status code of the main (focal) Act. Example: when sending a lab order jointly with an order to create a document with the labresults, one may want to specify that a document should only be created once the status of the lab observation is 'completed' - and nothing before that point in time.
 +
|-
 +
| Subject || Patient.id || Patient identifier. Also allow tuple (patient name, dob, gender)?
 +
|-
 +
| Author || Author.id || Who is asked to create the report (person/organization/software application)
 +
|+ '''Table 1'''  Items considered to be of use in a document order
 +
|}
  
The model should allow the ordering party to specify:
 
*The requested document type
 
*An interval of time for the data which should be reported on/documented
 
*The encounter.ID of the encounter which should be reported on/documented
 
*Identifier of the main (focal) requested/performed act
 
*Status code of the main (focal) Act. Example: when sending a lab order jointly with an order to create a document with the labresults, one may want to specify that a document should only be created once the status of the lab observation is 'completed' - and nothing before that point in time.
 
*Patient ID
 
**Patient Identifier
 
**Secundary identifying characteristics: patientAdministrativeGender, patientBirthTime, patientName
 
*Who is asked to create the report (person/organization/software application)
 
*Set of template IDs the document creator is requested to adhere to
 
  
 
==See Also==
 
==See Also==

Revision as of 10:18, 6 February 2009

Summary

This proposal documents a new set of HL7 version 3 interactions related to 'ordering the creation of a document'. The document could be of any mime-type, and could have a structured or a non-structured content. The focus will be on structured CDA (and more general: SDA) documents, but this should not preclude the interactions from being used for other documents.

The newly created set of interactions may become part of a new Topic in the RCMR (medical records) domain. The medical records domain is the responsability of the Structured Documents WG.

Use-case

  • Sending an order to request for the (human) creation of a clinical summary report; sending an order to request the creation (by a software application) of a lab result report.

Dynamic Model

In terms of Dynamic Model and Trigger Events the newly proposed Topic conforms to the general Orders and Requests Pattern as defined by the Orders and Observations WG. That design pattern will be used as the basis for this topic.

Static Model

The static model used in the order interactions has to indicate various items of metadata related to the document that should be created (e.g. requested document type, requested author, requested templates the document should conform to, patient id, etc.).

Requirements related to the static model:

  • The basic model (refined by further discussions) could be defined to be the CDA Header model, with the focal DOCCLIN Act in RQO mood.
  • The final model should be in compliance with the Composite Order model (as defined by the Orders and Observations WG). The current Compsite Order model may have to be updated to support the ordering of documents.
Grouping Request item Notes
Structure Document.code The requested document type
Structure Document.templateID Set of template IDs the document creator is requested to adhere to (only applicable for structured documents)
Structure Document.profileId The ProfileID (the implementation guide) the document creator is requested to adhere to (only applicable for structured documents)
Structure Document.mimeType The mime type the document creator is requested to create (if equal to application/hl7-v3-sda templateIds will have to be used to identify CDA R2, CDA R3, SPL, etc.)
Subject Activities.effectiveTime An interval of time for the data which should be reported on/documented
Subject Encounter.id The encounter.ID of the encounter which should be reported on/documented
Subject MainActivity.id Identifier of the main (focal) requested/performed act
Subject MainActivity.status Status code of the main (focal) Act. Example: when sending a lab order jointly with an order to create a document with the labresults, one may want to specify that a document should only be created once the status of the lab observation is 'completed' - and nothing before that point in time.
Subject Patient.id Patient identifier. Also allow tuple (patient name, dob, gender)?
Author Author.id Who is asked to create the report (person/organization/software application)
Table 1 Items considered to be of use in a document order


See Also

  • Vassil: If one were to look at methods outside of HL7,
    • one method could be the IHE ITI Registry Stored query (transaction 18): [1]
    • As a matter of fact, this year a change to the XCA profile [2] is going to introduce the concept of query to create a document on demand to transaction 38, Cross Gateway Query (which is based on transaction 18) - this seem to cover the case for "order for a document"...
  • Christof: QED - Query For existing Data, QBD query for bulk data.
  • René: the above ITI-18/ITI-38 and profiles are related to querying pre-existing documents. That isn't the case here. Some of the query parameters used in the query for-existing-document-characteristics are appropriate in the order interaction proposed on this page.
  • René: the same arguments apply to QED and QBD. In general (and this is probably the communality noticed by both Vassil as well as Christof): 'document metadata' is at the core of the document query interactions they refer to, and certainly 'document metadata' is a strong candidate for being considered to be included in the payload of the newly proposed order interaction.
  • Vassil: It is a change proposal, accepted to be worked on during this cycle: CP-ITI-401.
  • René: OK, this does discuss the creation of new documents. If one queries another 'affinity domain' (in IHE terms) the other domain may interpret a query as an order to create the document. This is a business arrangement which may exist between affinity domains. Sure: interpreting a query for a document as an order to create such a document may work in some settings. Some of the parameters used in a document query will be applicable in a document order, but other than that I don't think the IHE references provide us with a lot of useful information about the ordering of documents.