Order interaction for the creation of a document

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.

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.

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.

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).	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.	InrastructureRoot.templateID
Structure	Document.profileId	The ProfileID (the implementation guide) the document creator is requested to adhere to.	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.	this attribute (ClinicalDocument.profileId) doesn't exist in CDA R2, it is being proposed for CDA R3.
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.).	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.	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.	Act(DOCCLIN/RQO).languageCode. Note: Open issue. This attribute contains the language of the order act and strictly taken has no impact on the subsequent Act in EVN mood. 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.	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	OldDocument.id, Documentrelationship.code	Identification of the old document - the document author is requested to create a document which is a transformation/update/appendix (as specified by Documentrelationsip.code) of the OldDocument.	??? - 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.

Properties of the Requested Act

• Currently one has the ability to convey properties of the Request Act, but one doesn't have the ability to convey all properties of the requested act. Notably (in the context of this propsal): languageCode, profileId/mime-type/templateId. See MnM Hot Topic Properties of Requested Act vs properties of Request Act.

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.