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; (c) 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