Save encounter workflow

Hi Roger,

(I’ve cc’d in the architecture group as other may wish to comment further.)

(From a previous question:) I would expect that the PoC would encode its clinical data as a CDA document before it is sent to the IL. The IL will then be responsible for validating this and enriching it with additional identifiers.

To the question about the PCC templates, I would hope that these will generally allow for most of the important data to be represented in a standardised format. However, if there are additional item of clinical importance that are not represented, we would want to allow additional data elements to be added to the document even though they are not a part of the template. The PCC profiles allow for this.

In addition it would be possible to support any document within an XDS.b envelope so we could send in anything that is relevant, however, we would not expect these to be available as discrete data in the SHR, it will just be persisted as-is in a blob like format. We would try to only import standardised CDA documents such that the code can be reused rather than creating something implementation specific.

If there are particular PCC templates that we find lacking, then I believe the best course of action would be to make note of the problems and bring these to IHE so that they can be included in future releases.

Cheers,

Ryan

···

On Fri, Jun 6, 2014 at 4:06 PM, r.friedman@mindspring.com wrote:

Ryan, I have starting looking at the IHE PCC templates, and it seems to me that there are so many lacking that you couldn’t count on storing a medical record using them. Do you have any plans for ad hoc templates or anything?

Saludos, Roger

-----Original Message-----
From: Ryan Crichton
Sent: Jun 5, 2014 5:52 AM
To: Roger Friedman
Cc: “ohie-architecture@googlegroups.com

Subject: Re: Save encounter workflow

Hi Roger,

Thanks for sharing these. My responses are below:

  1. For saving an encounter to the SHR we will be using the XDS.b profile to transmit CDA documents. That profile describes the process which has to be followed to perform an update. I believe an update document must explicitly identify the document that it replaces. Each document will have a unique ID by which it can be referenced.
  2. I believe XDS.b specifies that we must use a unique identifier per document. We won’t be using a ‘natural key’ to reference these so there won’t be any collisions to worry about.
  3. We will be using profiled CDA documents to convey clinical encounters. Each of these has some specific template IDs by which they can be identified (for example an identifier for ‘Antepartum History and Physical’). The CDA document will also contain other metadata that describes exactly what sort of encounter it represents.
  4. This, I do not know. I’m no expert about services so perhaps we could have a further discussion about this. The source of truth for encounter types would likely be the set of supported CDA templates.
  5. I believe the CDA documents are able to maintain relationship with multiple people and their role in an encounter. Are you thinking of how this is handled in the exchange format or within OpenMRS?
    Hope this helps.

Cheers,

Ryan


Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

On Tue, Jun 3, 2014 at 2:56 PM, r.friedman@mindspring.com wrote:

In thinking about our discussion, I have some doubts. Quite a few relate to the SHR community, perhaps Ryan could speak for them?

(1) When saving an encounter, how do we know whether we are doing a create or an update? Is there a LEID (local encounter ID) being sent as part of the message? The natural key seems to be patient, provider, facility, date/time (to what granularity?), encounter type (if needed to make up for a lack of granularity in date/time). If a PoS wants to do an update in which any of the natural key elements change, must it do a delete and add? Do we ever say this explicitly?

(2) It seems that we should not rely on having a great deal of granularity for date/time, especially in post-entry environments or with historical data. This raises the possibility of multiple encounters with the same natural key, particularly in a hospital setting where vitals and other observations may be taken many times a day. Should warn before overwriting, use a LEID, or require greater time granularity for repeated encounters?

(3) Does every encounter have an encounter type? I think yes, even if it is some default, because it’s pretty key to identifying program activities. Is it more like HL7 PV1.4 (Patient Visit Segment, Admission Type field) or HL7 OBR.4 (Observation Request Segment, Universal Service ID field)? Given that HL7 ORCs (Order Control Segment) are contained in PV1 in parallel with OBRs, how can we use OBR.4 and still relate orders to encounters?

(4) What is the relationship between encounter types and services? Are/should they be the same? Where is the source of truth for encounter types?

(5) How do we handle multi-provider encounters?


You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail: ryan@jembi.org