Thanks for undertaking this, Carl. Just a couple of quick comments:
(1) The profile and profile template levels are not sufficiently granular for some purposes. For example, the “HIV ART Initiation” profile template would include a CD4 count obs, but that CD4 count might not have been done at the facility reporting ART Initiation; CD4 would be a service level of a lab. On the other hand, they can be too granular – we would not expect to see “ART Initiation” as a specialty or certification for a physician.
(2) My understanding is that the current InfoMan functionality is unidirectional from the registries to the merged and cross-indexed cache, and that CRUD against the FR and HWR are product-specific API operations. I’m unsure whether this is intentional or only reflects the current state of development.
···
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 (c). 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
On Jun 5, 2014, at 6:29 AM, r.friedman@mindspring.com r.friedman@mindspring.com wrote:
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
Hi Roger,
Thanks for sharing these. My responses are below:
- 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.
- 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.
- 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.
- 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.
- 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
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
-----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
–
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.
-----Original Message-----
From: Carl Leitner
Sent: Jun 5, 2014 9:23 AM
To: r.friedman@mindspring.com
Cc: Ryan Crichton , “ohie-architecture@googlegroups.com”
Subject: Re: Save encounter workflowHi,–
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.