Save encounter workflow

Thank you, Ryan.
Whose job is it to enCDA the data – PoS or IL?

I am trying to get my arms around the concept of a service. It seems we have multiple uses for the word which may or may not relate so well: (a) services are rendered by a provider to a patient during an encounter, which is encapsulated in a CDA profile; (b) a provider is capable of rendering a service, which is represented by a specialty or certification; © a facility is capable of providing a service, which is represented in the FR; (d) a payor will reimburse for particular services; (e) a vertical health program or plan of care will involve a series of services. In particular, there seem to be large differences in granularity, in that individual data values in the CDA profile may represent services in the payor or health program sense of the word, and provider services seem to be the least granular. The facility, program and payor senses seem to nest rather well. I guess it would be seeking a foolish consistency to try to come up with a single consistent definition, but perhaps we can come up with three or four different terms so we can know what we’re talking about and which objects/messages refer to which.

Saludos, Roger

···

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

Hi,

First, from the perspective of CSD, we are allowed to associate services to providers, facilities and organizations using potentially several different coding schemes. The data model for services, as well as other standardized lists, is fundamentally based on SVS.

I would imagine, for example, that there would be different coding schemes for a) through e). In fact there may be more than one for each — here I am thinking of, in particular the potential presence of multiple compensation schemes and payors (see in particular Figure 3):

http://jointlearningnetwork.org/sites/jlnstage.affinitybridge.com/files/IT-PPM_FINALlores_online.pdf

that may need to be supported either within one OpenHIE deployment and certainly OpenHIE would need to support these various use cases as it becomes deployed in multiple countries.

It would seem to me using the most granular level of service, e.g. (a) “clinical encounters”, should be the axis on which the notion of services in HIE rotates on. In particular it is needed for the SHR.

Working from this assumption it would be natural to expect there to be relationships between the services described in (a) and each on of (b)-(e). To spell out a few potential examples:

  • From (a) to ©. I have often seen an association between the facility type and the services that they are expected to provide, though I haven’t seen this expected in the granularity of (a). Thus we would presumably want to associate a facility type to subset of (a).
  • From (a) to (b), a healthcare worker with a particular speciality should inherit a subset of the services (a) as valid services offered by a provider. To add to the complication a bit, the association of a provider to a service is though the facility that he/she works at. Thus, this inheritance would need to be filtered through the services that are associated to the facility.

The point of the above is that as the basket of services changes under consideration changes, and they will, there will be a significant amount of “service association” maintenance that will need to happen. Thinking on how we can minimize the impact of such maintenance, I would propose that:

  • the TS would be a natural place to manage the relationships between (a) and the other types of service under consider, (b)-(e).
  • A change to any of these relationships should trigger a maintenance action on the InfoManager to update the various “service associations”.

I have tried to capture the essentials of this workflow below in the case of facilities. Here I am thinking of the “Service Relationship Manger” as a human interacting with the TS.

Cheers,

-carl

service_maintenence.png

···

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