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 13: Line 13:
 
==Dynamic Model==
 
==Dynamic Model==
 
In terms of [[Dynamic Model]] and [[Trigger Event]]s 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.
 
In terms of [[Dynamic Model]] and [[Trigger Event]]s 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.
 +
 +
Question: why an order, why not a query? A query requests that an existing document be sent to the querying party - the result of which may be 'there are no documents that match your query parameters'. In order requests the execution of a workflow: the creation of a new document.
  
 
==Static Model==
 
==Static Model==
Line 58: Line 60:
 
|+ '''Table 1'''  Items relevant for a document order
 
|+ '''Table 1'''  Items relevant for a document order
 
|}
 
|}
 +
 +
==WGM Phoenix, OO-Working Group 2010-01-20==
 +
*Proposal was presented.
 +
*Harry Solomon talks about a use-case whereby the result of the order is a Document Set. This wasn't part of the original set of use-cases, but we could try to ensure that the response model supports 1..* documents.
 +
*MOTION: In principle this topic fits with the OO Composite order domain, and OO will address how to progress this in a project. (Rene/Patrick, 13-0-1).
 +
**The current composite model project statement will be updated to include 'the POOR domain model will be extended to support the ordering of the creation of a document'.
 +
*Rene indicates that there is currently no urgent requirement for implementation, so having a solution in the D-MIM would be sufficient. In other words: no special Topic, no interactions, no R-MIMs.
 +
*Rene to create an R-MIM which acts as a focal point for discussion. Will be discussed on an OO teleconference call, and during the Rio WGM in May 2010.

Revision as of 17:30, 20 January 2010

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 should be part of the composite order (POOR) domain.

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.

Dutch Storyboards

  • (use case 1) Gerald General, a GP is informed (exactly how is out of scope of this simplified use-case description) that Patient Eve Everywoman has had an encounter with Radiologist Dr. Röntgen and Gynaecologist Dr. Gerard, both in the same hospital. Given that the GP has a responsibility in the provision of continuous care to the patient he sends an order for a 'consultant summary' to Dr. Röntgen, and another order for a 'consultant summary document' to Dr. Gerard. Dr. General stores the documents (and the information contained therein) in his GP system. When Eve shows up for a future GP consultation Dr. General has access to the data generated during the hospital encounter.
  • (use case 2, minor variation) Irvin Internist, a specialist in the area of internal medicine, is informed (exactly how is out of scope of this simplified use-case description) that Patient Eve Everywoman has had a prior encounter with another Internist Dr. Iznogood in a different hospital. Dr. Internist sends an order for a 'consultant summary document' to Dr. Iznogood. Dr. Internist stores the document (and the information contained therein) in his software application. When Eve shows up for a future encounter with Dr. Internist he has access to the data generated during the prior encounter.

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.

Question: why an order, why not a query? A query requests that an existing document be sent to the querying party - the result of which may be 'there are no documents that match your query parameters'. In order requests the execution of a workflow: the creation of a new document.

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 Composite Order model (order interaction) CDA R2 (response document)
Structure Document.code The requested document type. Act(DOCCLIN/RQO).code (new: DOCCLIN/RQO to be added as one of the Acts in the main choice box) ClinicalDocument.code
Structure Document.templateID Set of template IDs the document creator is requested to adhere to (only applicable for structured documents). Gschadow: This does not work, templateID is not part of the information model, just something that specifies the template for the structure that you send, i.e., in this case the structure of your order. Rene spronk True. We won't be able to support this part of the use case. not available
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.). (New, not in current POOR model: DOCCLIN DEF Act -- INST act relationship -- DOCCLIN RQO (focal act)). Act(DOCCLIN/DEF).text ClinicalDocument.text (although that attribute doesn't exist in CDA R2). There is a precedent for text to be used to solely convey the mime type, see ParentDocument.text
Structure Document.language The document language the document creator is requested to use. (New, not in current POOR model: DOCCLIN DEF Act -- INST act relationship -- DOCCLIN RQO (focal act)). Act(DOCCLIN/DEF).languageCode ClincalDocument.languageCode
Subject Activities.effectiveTime An interval of time for the data which should be reported on/documented. subject Act(EVN)
Note: No, it's not NOT Act(DOCCLIN/RQO).effectiveTime
ServiceEvent.effectiveTime, effectiveTime of entry-level Acts
Subject MainActivity.id ID of the main (focal) requested/performed act. subject Act(EVN) ;sourceOf(Actrelationship of type XXX)/requested Act.id (new: subject to ACT(EVN) to be added, the current model is limited to role based subjects) ServiceEvent.id, Order.id
Subject MainActivity.code Type of the main (focal) requested/performed act. May be used if there is no known MainActivity.id See MainActivity.id ServiceEvent.code, Order.code
Subject Encounter.id The encounter.ID of the encounter which should be reported on/documented. subject Act(EVN) ;sourceOf(Actrelationship of type XXX)/requested Act.id EncompassingEncounter.id
Subject Encounter.code The type of encounter which should be reported on/documented. May be used if there is no known Encounter.id See Encounter.id EncompassingEncounter.code
Subject RecordTarget.id RecordTarget (mostly: Patient) identifier. recordTarget/R_Subject.id PatientRole.id
Subject ReferencedDocument.id, Documentrelationship.code Identification of a referenced document - the document author is requested to create a document which is a transformation/update/appendix (as specified by Documentrelationsip.code) of the ReferencedDocument. ??? - There are open modelling issues related to how this should be modelled in a v3 artefact: see section below on Properties of the requested Act. relatedDocument/ParentDocument.
Author Author.id Who (as an identified Role) is asked to create the report (person/organization/software application). performer/(Role).id AssignedAuthor.id
Author Author.code Who (of what kind) is asked to create the report (person/organization/software application). The underlying use case is one whereby one would like 'a lab physician' to write the report without the requirement to identify an individual. performer/(Role).code AssignedAuthor.code
Recipient Recipient.id If other than the author of the order to create a document. "resulting document to:" callBackContact/R_NotificationParty IntendedRecipient.id
Timing Order.priorityCode The priority of the order to create a document Act(DOCCLIN/RQO).priorityCode n.a.
Timing 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.
The Composite Order model has a mechanism to indicate that one order should be performed after (SUCC act relationship) another order.
sourceOf(Actrelationship of type SUCC)/requested Act.id ServiceEvent.statusCode (although that attribute doesn't exist in that class), status of the Entry-level acts.
Table 1 Items relevant for a document order

WGM Phoenix, OO-Working Group 2010-01-20

  • Proposal was presented.
  • Harry Solomon talks about a use-case whereby the result of the order is a Document Set. This wasn't part of the original set of use-cases, but we could try to ensure that the response model supports 1..* documents.
  • MOTION: In principle this topic fits with the OO Composite order domain, and OO will address how to progress this in a project. (Rene/Patrick, 13-0-1).
    • The current composite model project statement will be updated to include 'the POOR domain model will be extended to support the ordering of the creation of a document'.
  • Rene indicates that there is currently no urgent requirement for implementation, so having a solution in the D-MIM would be sufficient. In other words: no special Topic, no interactions, no R-MIMs.
  • Rene to create an R-MIM which acts as a focal point for discussion. Will be discussed on an OO teleconference call, and during the Rio WGM in May 2010.