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

Canadian Storyboards

• Eve Everywoman has been referred by Dr. Beaker to another provider (Dr Oncologist) for a consult. While Dr. Beaker has received a paper copy of a specific lab result from the lab. Dr. Beaker needs an 'legally authenticated', electronic 'document' to communicate to the consulting provider. Dr. Breaker 'orders a document' for the lab result from the lab.
  • CLARIFICATION QUESTION: does this mean that (a) the response CDA document SHALL contain a legalAuthenticator participation, or (b) that the response CDA document SHALL be an authenticated document (irrespective of if and how, it may be contained in the document itself, or maybe in a SOAP header, or it may not be explicitely present at all) document. A implies that B has happened, but B does not imply A. It's not clear from the use-case whether A or B applies. Rene spronk 18:56, 20 May 2010 (UTC)

New Zealand Storyboards

• Mrs V Ursula N Hapi, for a variety of reasons, has finally decided that she can no longer continue to visit her usual GP, Dr I S Deaf. However, she is unable to summon up the courage to approach practice nurse, Nurse I Fiona U Dare, to request that her records be transferred to a new GP who seems far more disposed to address her ailments, Dr E M Pathetic. This use case describes the ability of Dr Pathetic's Practice Management System (PMS) to request that all records relevant to Mrs Hapi's prior primary healthcare at the rooms of Dr Deaf be transferred to it in the form of a collection of document(s). The collection of documents includes an overarching summary document with associated supporting documents, notably scanned versions of letters received by Dr Deaf.

IHE Use-cases

• The Deferred Document and Dynamically Created Content profile (D3S) (a draft 2010 proposal to extend the XDS set of profiles available in ITI TF) document the use-case whereby the Dynamic Document Source actor has the capability to create an on-the-fly document if and only if the document is queried for (i.e. in HL7 terms: when ordered to create) the document.
  • The request always returns the most current content available to the responder. The use of dynamically created content is intended for an application architecture where the supplier of data wishes to provide, through a single request mechanism, the most current information available at the time of request. The dynamic nature of the data means this environment is more complicated to support bu allows easy access to, for instance, summary data for a specific patient. However, it does not provide for robust source attestation of the overall document content because the content is selected by a computer algorithm rather than overseen and attested in whole by a clinician.
  • The request parameters are limited to the available metadata fields in the XDS registry. These include: patientId, document type, type of clinical event being documented, time interval of the clinical event, language, author, author's organization, legal authenticator, mime type, document relationship.

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.

Questions:

1. 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.
2. Charlie McCay: This is very like the usecase being addressed by ISO/CEN 13606:5 - is there any chance of this being a combined effort?

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

Note: some of the act relationships used may (still) point in the wrong direction. The model should suffice to get an idea of what it would take to satisfy the use-cases documented above.

Model walkthough

The focal act is the ClinicalDocumentEvent act.