And VNA has no notion of whether a patient is admitted or not - only that prefetch is required. The A01 from initial admission has done that work already, so there is nothing for VNA to do.
So When a Lab visit is initiated, Lab sends A01 to VNA only. VNA treats that as a prefetch request. As far as PAS (and any other system for which admission is relevant), nothing has changed.
posted on Thursday, August 28, 2014 - 07:53 pm
Wot nick said. Some of us are young enough not to really remember reporting stacks of plain film at all. 'At least as quick as it used to be' is not helpful. One could validly argue that the benefit of dynamic re-windowing of a poorly-penetrated CXR, is of more clinical value to a reporter than a second or two in display time. Comparing PACS with film, is like comparing apples with frogs.
Lots of people have great ideas about what the optimal system should be. However lots of us have ended up with different 'optimal' systems. Diversity is a great thing as it encourages competitors to keep developing their products.
I'm a clinician and I like to think I know my clinical service and skillset really well. I don't pretend to have the same depth of knowledge and skill in IT, but I want to work with someone who _does_ have that level of expertise in their field.
By describing the end-points in predominantly clinical terms (what I know well) and relying on the technical expertise (what they know well) of IT companies to come up with solutions to fill in the blanks, some really innovative suggestions pop out along the way.
Currently PASes send out A01 and A03 messages for Ward admissions and discharges to RIS and PACS. VNAs could use current A01 and A03 for prefetch.
RIS sends out HL7 ORM messages to PACS when a patient "visits" radiology. VNA could receive ORM for prefetch.
However, it still does not resolve the issue of when patients "visits" A&E, OPDs, etc I dont think A01 and A03 should be "abused" for VNA prefetch purposes. I think we should leave A01 and A03 to deal with inpatient episodes.
Regarding, 1sec, 3sec, 10sec or 30sec for display of current image and priors, I think it should be clearly written in the contract by individual Trusts--which is agreed with the local radiologists. Suppliers would NOT get paid unless they deliver what is in the contract. For ourselves, we have written 3secs for current and all priors for 8years. All our priors are local. This is being delivered at a much cheaper price than LSP contracts.
We are capable of regional or national sharing with any interested organisation using PIX manager for PDQ queries and XCA due to our investment in XDS within the VNA. Obviously we will need to agree on display times which will obviously depend on network capabilities of N3/N4.
Having said what I have said, I personally think that a combination of HL7 ADT A01 triggers from PAS and HL7 ORM triggers from RIS, can deal with majority of times radiologists and clinicians would review a patient's images. A&E doctors would look at images either after they request one--after HL7 ORM or if the patient has had imaging done in the last 6weeks. Once prefetched, if VNA/PACS keeps all the patient's images for 6months in the "fast layer" I think we will cover most eventualities. I agree "intelligent prefetch" could be used.
posted on Saturday, August 30, 2014 - 03:45 pm
Guidance by HL7 UK (and HSCIC when it comes to HL7 v2) is that an A04 should be used to denote that an 'outpatient visit has started' - their guidance fits with the usual practice.
A03 is used to end both an outpatient as well as an inpatient visit. A01 (as you said) is used only for inpatients. Prior to an in/outpatuient visit a A05 (pre-admit) could be used as well.
Next to ORM messages SIU (scheduling messages), if used by PAS and/or RIS could play a role in prefetching as well.
Neelam, there is no "abuse" involved in using A01.
A01 is defined in HL7 as "admit/visit notification" and it is NOT specific to in-patient hospital (ward) admissions.
So, it is entirely appropriate for visits to the A&E department, and for visits to outpatient clinics.
I also suggest that it may be very useful for prior images and reports to be fetched for A&E visits so that the doctor can look at them BEFORE ordering an unnecessary imaging test. Ideally this would include outside studies (e.g., that the local GP may have recently ordered for the same problem that just got worse).
Another option is to look for other signs of activity about a patient, if the A&E and Outpatient management systems that you have do not send ADT messages. For example, you can look for lab orders that originate in A&E.
PS. I quote from HL7 V2.3 Chapter 3 Patient Administration:
"We recognize that different hospital systems use different definitions of the terms “inpatient,” “outpatient,” “emergency room,” and “recurring patient classes,” or handle these patients differently. Therefore, the trigger events are not defined as specific to any patient class. ... In order to accommodate non-admitted patient events without using the same trigger events as those for admitted patients, we would need an entirely new set of non-admitted patient events. If we do that, disparate systems would still have a hard time agreeing about whether certain patient classes should use the admitted patient events or the non-admitted patient events, because of the differences between how admitted and non-admitted patients are defined and handled. Both admitted and non-admitted patient events are transmitted using most of the same events. The meaning or interpretation of those events will depend upon the patient class."
You say A04 could be used to denote that "Outpatient visit has started"--i.e. the patient has an "arrived status" in Outpatients 2 further questions for you: 1. Could we use this for A&E visit as well? 2. What trigger would be used to inform that the patient has "left outpatient department"?
I re-read your comment. You say that "A03 is used to end both an outpatient as well as an inpatient visit."
This is whrere the problem is Patient is in ward 16 under Physicians.--A01 trigger with field 3--Ward 16 Visits Gynae OPD whilst as inpatient--A04 trigger with field 11 --Gynae OPD Leaves Gynae OPD back to the Ward 16. Will the A03 trigger discharge the patient from ward 16 too?
HL7 v3 describes them as encounters 1. Inpatient admissions 2. Outpatient 3. Emergency And there are separate triggers for arrival and discharge from each type of encounter.
posted on Sunday, August 31, 2014 - 10:01 am
@David: whilst A01 is certainly flexible - its definition does however explicitely state that for an A01 "the patient is assigned to a bed". In cases where there is no such assignment, A04 should be used.
HL7 version 2 really only supports encounters at the hospital level - admits and discharges are always related to this one overarching administrative encounter. There is no support for sub-encounters with departments, and no support for 'clinical encounters' (pathways, or whatever term one wishes to use)
The way to support your example use case is as follows:
1. Patient is in ward 16 under Physicians.--A01 trigger with field 3--Ward 16 2. Visits Gynae OPD whilst as inpatient--A10 (patient arriving - tracking) 3. Leaves Gynae OPD back to the Ward 16. -- A09 (patient departing - tracking) 4. Leaves hospital upon discharge -- A03
A09 and A10 are about 'tracking the patient' - the patient is not assigned to a different bed, so all we're doing is physically tracking their whereabouts. (this is supported and described in the UK HL7 v2 specs, as well as in the HSCIC ITK).
The problem is that whereas many PAS/HIS systems will support A09/A10 (though it's main use is to do tracking to ORs for surgical procedures and other lengthy periods where the patient is not physically in his/her bed), a lot of RIS/PACS/VNA systems probably won't. A message broker / communication server will them probably choose to translate A10/A09 into A04/A03 or A01/A03 (using a made up visit number) which is the closest equivalent.
Certainly A01 does say "assigned to a bed", but it also provides examples of using it:
"to notify: the pharmacy system that a patient has been admitted and may be legitimately prescribed drugs; the nursing system that the patient has been admitted and needs a care plan prepared; the finance system of the start of the billing period; the dietary system that a new patient has been installed and requires dietary services; the laboratory, pathology, and radiology systems that a patient has been admitted and is entitled to receive services; the clinical repository that an admission has taken place for the EMR (electronic medical record)."
and there seems to be significant overlap in some of those purposes with what we are discussing (triggering pre-fetch), as well as a relevance to A&E.
It is the case that A04 trigger events are described as signalling "that the patient has arrived or checked in as a one-time, or recurring outpatient, and is not assigned to a bed", and further "that some systems refer to these events as outpatient registrations or emergency admissions". The text does not seem to consider the need to order tests or prescribe drugs or contribute to the EMR in the context of A04 triggers, but presumably that is an oversight, and as you say, a result of an excessive focus on "hospital" (inpatient) systems.
Do any systems distinguish the A&E visitor sitting in a chair (A04?), from them one lying on a cart (bed? A01?) in this respect? And what about those patients who hang about on carts in A&E for days when no ward beds are available and then get discharged/die (are they ever "admitted", get an A01 if A04 was used earlier)?
And when does the trigger event occur, when the admitting officer in A&E says they are to be admitted? Some administrative person types it in? They actually arrive on the ward?
Anyway, if I were a PACS and got either an A01 or an A04 (or an A05 pre-admit, A14 pending admit, or I suppose an A10 patient arriving/tracking) from A&E (or anywhere else), I would think pre-fetching would be indicated, regardless of the trigger event. By comparison, IHE SWF specifically calls for support of A01, A04 and A05 in RAD-1 "Patient Registration".
Speaking of IHE, since the RAD-1 transaction in SWF does not go to the IM/IA (and RAD-4 Procedure Scheduled, which does, is "too late" for some use cases), one wonders if there is a need for an SWF option or a separate profile to address "pre-fetching" triggers, behavior, and perhaps the involvement of pre-fetching via MIMA and XDS from other sources (with the appropriate IRWF coercion semantics for identifiers and codes). Perhaps these would be separate options ("local" vs. "remote" pre-fetch, as was discussed earlier).
PS. On the other side of this equation, when one gets the various Axx ADT messages signalling the patient's departure, one might also consider (starting a timer before) removing the images from the fast storage, on the assumption that if they were needed again, a new arrival trigger (or scheduling of an outpatient appointment) would reset the timer or bring them back. I mention this since it might mitigate the anxiety of those who are concerned that emphasizing sensitivity over specificity for pre-fetching might result in an overly large amount of fast storage required. The early literature discusses this (e.g., Wong 1994: "until the patient is discharged, transferred, or other aging criterion (for example, two days after an outpatient visit)" "http://dx.doi.org/10.1117/12.174293"). That would rapidly purge the studies for the folks who visit A&E with runny noses, cuts and bruises. This could also be part of an IHE pre-fetch profile/option.
PPS. Since Martin objected to my old-fashioned use of the term "spinning" before, since SSDs are not spinning and spinning HDs may be tiered in various speeds, I will just use "fast storage" as applying to whatever form of storage is necessary to guarantee near-instantaneous access, regardless of what storage medium is used (and avoid the use of the term "cache", which has other connotations).
posted on Sunday, August 31, 2014 - 04:16 pm
>> Anyway, if I were a PACS and got either an A01 or an A04 (or an A05 pre-admit, A14 pending admit, or I suppose an A10 patient arriving/tracking) from A&E (or anywhere else), I would think pre-fetching would be indicated, regardless of the trigger event.
I fully agree. One can argue about the details of the various v2 trigger events (and the variance in implementation thereof), but for the purpose of this discussion the above is what it comes down to.
posted on Monday, September 01, 2014 - 10:18 am
This has been a very interesting posting and some of the items that have been listed have a lot of sense but this has not looked at the fundamental argument on image retrieval times. The triggers enable access to patient date where information needs to be moved from system to system but my understanding would be to have the data in a central store-VNA etc. and allow systems to access it on demand - this is old school technology. I think the requirements of a reporting Radiologist are very different to others who require access to this patient information. I have been speaking to some of my friends who are A&E consultants and asked them what they require as they do not have time to look for too much at the first showing of the patient. Although the GP records would be the most useful. As for images, only those at the time of the examination are required but fast access to others may be looked at but not a requirement. General patient records are a must. So I would recommend that a good workflow of different users is made. I think the requirement of fast storage on PACS for the long term is a thing of the past for general viewing, but having this on a central VNA using an enterprise viewing app. that can be integrated in to a PAS of RIS using a URL should be the future. This allows the user to decide what they need using different devices through a patient portal or something similar.
posted on Monday, September 01, 2014 - 10:06 pm
I would like to see if a simple approach would work for pre-fetch for all departments that a patient may visit:
HL7 ADT A01 trigger for inaptient admission HL7 ADT A04 trigger for A&E visit (Rene do you think this is the best trigger for A&E visit) HL7 ORM for visit for investigations--radiology, lab etc HL7 SUI--S12 for new appointment booking for OPD
Once a trigger is sent, we should have the images in the "fast layer" for 6 months.
What do you think Rene, David and Martin?
posted on Tuesday, September 02, 2014 - 11:11 am
I am not sure if you have an enterprise viewer and XDS,XDSi, URL connection why do you need to prefetch? Is this information in the VNA so the key is providing a portal to gain access to it or am I missing something? I think having 18 to 24 month fast access in the PACS provides the necessary availability of information also with those special patients requiring long term treatment these triggers to not delete from the PACS fast store should be set up. Good workflow planning is the key. This should be worked out as part of the purchasing exercise as asking the vendor to change the system can be expensive.
posted on Wednesday, September 03, 2014 - 06:52 pm
I had an interestign discussion with our HL7 expert in our hospital. We have Totalcare PAS from McKesson Symphony A&E system Ensemble(HL7 engine) recieves all HL7 messages from various systems and send them out to any interested system. PACS and RIS receive ad send all HL7 messages from Ensemble.
A01--(HL7--Admit) is used for inpatient admission and is sent by McKesson PAS A04--(HL7--Register a patient)--is used for A&E visit sent by Symphony (not PAS) A05--(HL7--Preadmit patient)--is used by OPD visit and is sent by McKesson PAS (which is used for scheduling OPD appointments)
A03-is sent by Symphony and also Mckesson and used to discharge the patient from Wards and A&E
A08--(Hl7--update patient information) is used for "discharge" from OPD
Field 3 of PV1 segment (HL7--assigned patient location)--could be used for Inpatient location Field 11 of PV1 segment (HL7 -temporary location)--could be used for OPD location
So to summarise we would need VNA/PACS to recieve the following HL7 triggers to do pre-fetch of full patient imaging history: 1. A01 2. A04 3. A05 4. O01--Order message fromRIS or labs
Once prefetched, the images and documents should remain in the "fast access layer" for a minimum of 18 months. Locally we would just need to get VNA connected to recieve these triggers from Ensemble
posted on Saturday, September 06, 2014 - 06:31 am
"Anyway, if I were a PACS and got either an A01 or an A04 (or an A05 pre-admit, A14 pending admit, or I suppose an A10 patient arriving/tracking) from A&E (or anywhere else), I would think pre-fetching would be indicated, regardless of the trigger event. "
I agree with Rene. PACS or VNA should get the following prefetch triggers to move imaging to the fast layer 1. Inpatient admission (HL7 ADT -A01 or other trigger sent by PAS) 2. A&E visit (HL7 ADT --A01 or other trigger sent by A&E system) 3. Outpatient visit (HL7 SUI-S12 or other trigger sent by Outpatient Scheduling system) 4. Investigations visit--(HL7 ORM --O01 or other trigger sent by RIS, CVIS, lab systems etc)
How long should images stay in the fast layer--6weeks, 6 months, 18 months--local decsions can be taken based on cost. I personally think 3-6months would be adequate.