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
 
(17 intermediate revisions by 2 users not shown)
Line 12: Line 12:
  
 
===Canadian Storyboards===
 
===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.  
+
*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.
 +
**In CDA terms, the response CDA document is has to contain a legalAuthenticator participation. This type of requirement with regards to the content of the requested document is covered by the ClinicalDocumentDefinition.id attribute. See model walkthrough below.
  
===New Zealand Soryboards===
+
===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.
 
*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==
 
==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.
+
Questions:  
 +
#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.
 +
#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==
 
==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.).
 
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.).
  
==R-MIM==
+
[[image:Ordering creation cda.png|900px|thumb|center]]  
Note: some of the act relationships may 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.
 
[[Image:Ordering creation cda.png]]
 
 
 
===Discussion related to the R-MIM===
 
*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?
 
  
==detailed Requirements analysis==
+
===Model walkthough===
Requirements related to the static model:
+
The focal act is the '''ClinicalDocumentRequest''' act. This act contains the details of the request activity.
*The basic model (refined by further discussions) could be defined to be the [[CDA Header]] model, with the focal DOCCLIN Act in RQO mood.
+
*id: the identification of the request activity.
*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.
+
*code: the type of document that is being requested. Usually a code from the LOINC coding system.
 +
*effectiveTime: ''(standard wording)''
 +
*priorityCode: ''(standard wording)''
 +
*confidentialiltyCode: ''(standard wording)''
  
{| class="prettytable" width="100%" border="1"
+
The '''participations''' on the left-hand side of the model are copied from the POOR domain. A relevant subset is shown. See POOR for documentation.
|- style="background-color:#AFEEEE; text-align:left;"
 
! Grouping !! Request item !! Notes !! [http://www.hl7.org/v3ballot2008sep/html/domains/uvor/editable/POOR_RM200999UV.htm 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).  || [[User:Gschadow|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.'' [[User:Rene spronk|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) <br/> 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. <br/> 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
 
|}
 
  
==Discussion==
+
The '''instantiation''' association and the '''ClinicalDocumentDefinition''' class can be used to identify characteristics of the requested document. The ClinicalDocumentDefinition class has the follwoing attributes:
 +
*id: the identification of definition of a document structure, i.e. a document-level templateID. Example: the OID of CCD, or the OID of IHE Laboratory Report, or the OID for German Discharge Letter.
 +
*text: the mime-type of the requested document, e.g. the mime-type for CDA, or PDF. Note that the use of this attribute is constraint to conveying the mime-type. The value of this attribute SHALL not be in conflict with any requirements as defined in the template identified by the id attribute (if present).
 +
*languageCode: the language of the requested document, e.g. French. The value of this attribute SHALL not be in conflict with any requirements as defined in the template identified by the id attribute (if present).
  
===WGM Phoenix, OO-Working Group 2010-01-20===
+
The '''subject''' association and the '''ServiceEvent''' class are used to identify the activities which should be documented in (be the subject of the) requested document. The ServiceEvent class could be a procedure, an observation, or an encounter. ServiceEvent has the following attributes:
*Proposal was presented.
+
*id: identification of the event that should be documented
*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.
+
*code: type of activity that should be documented
*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).
+
**If code is the only attribute that has a value, one can support the use-case whereby one requests that "all encounters be documented", or "all laboratory tests".
**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'.
+
*effectiveTime: any activities within this time interval are requested to be documented
*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.
+
**If effectiveTime is used in combination with the code attribute one can support the use-case of requesting documentation of "all encounters that took place last year".
*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.
+
*the subject (the Patient) of the ServiceEvent class hasn't been explicitly modelled: it is available as the subject/R_Participation on the left hand side of the model, which conducts to the ServiceEvent act.  
 +
**Note: ''the new context conduction could be used to explicitley model this conduction.''
  
===WGM Rio, OO-working group, 2010-05-19===
+
The '''targetOf''' association and the '''ActIntent''' class are used to support the use-case whereby a document should only be created '''after''' the completion of a request. Example: a request to create a laboratory result document should be performed after the laboratory order has been completed (i.e. when the final results are available). ActIntent has the following attributes:
 +
*id: the identification of a request (placer order number) or a promise activity (filler order number)
  
*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.
+
The '''inFullmentOf''' association (and the '''ServiceEvent/ActIntent''' classes) is used to support the use-case where the party that requests certain activities to be documented doesn't have the identifier of those activities, but it does know the identifier of the order that lead to the activities. Example: if one first requests a laboratory test to be done (with placer ID 123), and one subsequently requests that a document be created for all lab results associated with the lab order 123. In this case the attributes in the ServiceEvent class won't be valued, and ActIntent.id shall be valued with 123.
**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===
+
==Discussion==
*(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, October 2010 WGM in Cambridge, Wednesday Q1:
 +
**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 this  version of the proposal]) 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
 +
*For other (older parts) of the discussion, as well as a record from discussions during WGMs, see the [http://wiki.hl7.org/index.php?title=Talk:Order_interaction_for_the_creation_of_a_document associated Talk page].

Latest revision as of 12:50, 19 October 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.

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.
    • In CDA terms, the response CDA document is has to contain a legalAuthenticator participation. This type of requirement with regards to the content of the requested document is covered by the ClinicalDocumentDefinition.id attribute. See model walkthrough below.

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

Ordering creation cda.png

Model walkthough

The focal act is the ClinicalDocumentRequest act. This act contains the details of the request activity.

  • id: the identification of the request activity.
  • code: the type of document that is being requested. Usually a code from the LOINC coding system.
  • effectiveTime: (standard wording)
  • priorityCode: (standard wording)
  • confidentialiltyCode: (standard wording)

The participations on the left-hand side of the model are copied from the POOR domain. A relevant subset is shown. See POOR for documentation.

The instantiation association and the ClinicalDocumentDefinition class can be used to identify characteristics of the requested document. The ClinicalDocumentDefinition class has the follwoing attributes:

  • id: the identification of definition of a document structure, i.e. a document-level templateID. Example: the OID of CCD, or the OID of IHE Laboratory Report, or the OID for German Discharge Letter.
  • text: the mime-type of the requested document, e.g. the mime-type for CDA, or PDF. Note that the use of this attribute is constraint to conveying the mime-type. The value of this attribute SHALL not be in conflict with any requirements as defined in the template identified by the id attribute (if present).
  • languageCode: the language of the requested document, e.g. French. The value of this attribute SHALL not be in conflict with any requirements as defined in the template identified by the id attribute (if present).

The subject association and the ServiceEvent class are used to identify the activities which should be documented in (be the subject of the) requested document. The ServiceEvent class could be a procedure, an observation, or an encounter. ServiceEvent has the following attributes:

  • id: identification of the event that should be documented
  • code: type of activity that should be documented
    • If code is the only attribute that has a value, one can support the use-case whereby one requests that "all encounters be documented", or "all laboratory tests".
  • effectiveTime: any activities within this time interval are requested to be documented
    • If effectiveTime is used in combination with the code attribute one can support the use-case of requesting documentation of "all encounters that took place last year".
  • the subject (the Patient) of the ServiceEvent class hasn't been explicitly modelled: it is available as the subject/R_Participation on the left hand side of the model, which conducts to the ServiceEvent act.
    • Note: the new context conduction could be used to explicitley model this conduction.

The targetOf association and the ActIntent class are used to support the use-case whereby a document should only be created after the completion of a request. Example: a request to create a laboratory result document should be performed after the laboratory order has been completed (i.e. when the final results are available). ActIntent has the following attributes:

  • id: the identification of a request (placer order number) or a promise activity (filler order number)

The inFullmentOf association (and the ServiceEvent/ActIntent classes) is used to support the use-case where the party that requests certain activities to be documented doesn't have the identifier of those activities, but it does know the identifier of the order that lead to the activities. Example: if one first requests a laboratory test to be done (with placer ID 123), and one subsequently requests that a document be created for all lab results associated with the lab order 123. In this case the attributes in the ServiceEvent class won't be valued, and ActIntent.id shall be valued with 123.

Discussion

  • OO, October 2010 WGM in Cambridge, Wednesday Q1:
    • Motion to accept the current Document Order use case, model, and walkthrough description (this version of the proposal) 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
  • For other (older parts) of the discussion, as well as a record from discussions during WGMs, see the associated Talk page.