Talk:Order interaction for the creation of a document

detailed Requirements analysis

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.

Table 1 Items relevant for a document order

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.	See section "Requesting a translation of a document" below for discussion	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.

Discussion

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.

WGM Rio, OO-working group, 2010-05-19

• The following Canadian use-case was considered to be out of scope of this work item. It should be solved by a model that has the "translation activity in RQO mood" as its focual act, with a subject that is the (id of) the Document which needs to be translated.
  • Use-case: Dr. Oncologist doesn't speak English. Therefore Dr. Breaker 'orders a document' requesting translation of a current electronic document from lab.
  • Historic background info: Discussion in MnM 2010-01-22, Lloyd suggests that this use case be covered by by a different model, one that has the entry point on a (Translation RQO) act, with subject (referencedDocument), and instantiates relationship with a DOCCLIN/DEF (for the requested language or mime type). Different R-MIM if we feel strongly about the use case.

WGM Rio, MnM working group, 2010-05-20

• (from the MnM minutes) Discussed Order interaction for the creation of a document open issue from Rene. Agreed that using an id attribute on the [ClinicalDocument] definition was a good way to reference an external template. The actual construction of a template that provides constraints on vocabulary, cardinalities, etc. in RIM terms is still a problem, but that's outside the scope of the issue raised.

OO teleconference, 20100714

Document Order – Rene Spronk

• The proposal relates to an order to create a CDA document.
• It looks like we need extension for existing DMIM
• Entry point: Clinical document in request mood
• Is arrow direction for act participations correct?– yes, but instantiation is reversed – source is instantiation of the target (inherited form parent concept sequel)
• Do we need to include patient? What if I want you create documents for all events for patient X over the last 6 months, versus a specific - do we need to explicitly state the patient?
  • Record target is assumed to be a patient in CDA header.
  • Following the composite order we need to explicitly state the patient using subject participation, unless we assume the participations listed are just shorthand for all participations available in the composite order model overall.
  • If that’s the case include a sentence that shown here are only the most relevant participations for this use case, but is not meant to be exclusive.
• New Zealand is asking for interactions – check WG minutes for names to see, if they can write this up. (post meeting notes: possibly Steven Chu, Richard Dixon Hughes, David Fallas)

OO, October 2010 WGM

• Order does not care
• The order assumes that the content materials are already available and do not imply an order to create the content. E.g., if the document ordered requires the presence of an X-ray and that X-ray is not (yet) available, then the document order does not constitute an order to take the X-ray.
• Question is how much this type of order is implying additional interpretation based on the combination of data. A second read or re-interpretation is not implied. I.e., there is no expectation that any additional or re-interpretation is performed. It is purely within the responding clinician’s purview to provide additional interpretation based on the combination of results being included. Any procedural requirements to record that additional interpretation are completely out of scope of this document order flow.
• Need to ensure new context conduction considers the need to conduct the subject into the Service Event (Patrick to check with Rene).
• Question raised whether Author and Recipient should move to the choice box. Conclusion is that there is no real use case where copies should be provided to the patient or the patient is the author of the request. If that comes up (PHR functional need) we will consider moving to the choice.
• Question raised whether in a SOA service representation should or should not take aspects of the model into the service construct, keep in the payload, or duplicate in both so payload is consistent between service and message transport method. Similar concern between message and document.
  • Key concern is whether in moving the payload model from one interoperability paradigm to another moves payload content (e.g., author) from the payload to the appropriate interoperability paradigm location, or copy that payload content
  • Needs to be raised with SAIF, MnM, ARB, et al.
• Motion to accept the current Document Order use case, model, and walkthrough description (http://wiki.hl7.org/index.php?title=Order_interaction_for_the_creation_of_a_document&oldid=39217) for inclusion into the Composite Order Model. As the merge progresses we may need to go back to the authors to validate and/or adjust the Document Order model/walkthrough. Rene Spronk, Lorraine Constable.
  • Against: 0; Abstain: 0; In Favor: 11

Other discussion points

• 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.