JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for GP-UK Archives


GP-UK Archives

GP-UK Archives


GP-UK@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

GP-UK Home

GP-UK Home

GP-UK  1996

GP-UK 1996

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: Security and the Web for Healthcare systems

From:

Rob Tweed <[log in to unmask]>

Reply-To:

[log in to unmask]

Date:

Fri, 04 Oct 1996 12:26:02 GMT

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (172 lines)

John

>Very interesting.  Can you enlarge on 'fully transactional (read +
>write) systems'?  Are there any accessible sites running this kind of
>system and what SW would one need to access them?  I find it difficult
>to picture what exactly would be exchanged in this way and how it would
>be treated by the receiving system.  

Basically the Web used in the way I am suggesting allows you to drop
the mental and/or physical association that we have all made over the
years between information and computer systems.  What I mean by that
is that, if you think about it, the only reason we think in terms of
exchanging information (eg between hospital and GP say), is because we
always assume that you (the GP) can only view, print, analyse,
manipulate or whatever some relevant  information the hospital
obtained about a patient by actually acquiring a copy of that
information yourself and having it incorporated in your computer
system's database structure for subsequent use.

With the Web approach, all those forms of access to the patient's
information that you require could, in theory at least, be achieved
via a Web browser on your desktop, via network connections to the
hospital(s) etc that have the various bits of relevant information
about the patient (direct connection, NWN, Internet via tunnelling
protocol etc), and via a Web-enabled linkage to the hospitals' (and
other) systems.  Your browser and the network provide the integration
mechanism.  And think of your GP system as just one source of the
patient's total record, and just one place your browser could be
pointed at to retrieve the total information.  A distributed patient
record ?

Now this is radical stuff !  So let's take it one step at a time.

At its simplest, then, with only a Web browser and a suitable network
connection, you could gain access to other NHS organisation's systems,
via HTML forms and other dynamic web pages generated by their system
to allow you limited access (under their control) to the information
they hold.  Your Web browser is, if you like, a dumb terminal (albeit
a bloody clever one!) giving access to their system - you're just
another user of their system (full transactional read/write access,
albeit with special, limited access rights).  Navigation through their
system is presented to you as a series of forms and hyperlink menus.
Presentation of the information you want is in the form of HTML pages
marked up "on the fly" according to the actual content of the
patient's information.  That information could include not only
textual information but also images and sound files associated with
the patient (X Rays, radiologist's dictated reports, etc).  That would
be then down to local GPs and the hospital to determine what
information and in what media is it beneficial for you to have access
to it. 

Taken to its further limits however, your Web browser can provide the
means to pull together the relevant bits of the patient record onto
your screen.  Developments such as frames, Active X components and
Java objects etc mean the relevance of the "system" - ie the physical
location of the information - becomes blurred if not irrelevant.

Clearly this is dependant on a number of things happening and being
available, so we're not there yet, but it's not difficult (and IMHO is
inevitable because this is exactly where Netscape, Microsoft, Oracle
etc are taking things anyway):

- readily available high bandwidth comms at a reasonable cost.  Note
the recent postings about Cable company activities in this area
though.  And of course there's always the NHS Network :-)  IMHO high
bandwidth at reasonable cost will soon not be an issue for all sorts
of reasons.

- the realisation of users that this is not fantasy but all eminently
do-able using current and emerging Web technologies (which is where
the big fast developments are occurring anyway so it's not going out
on a limb or backing a dubious horse) and existing systems (albeit
with some Web-enabling work being needed to those apps - but not
complete replacement).  As that realisation spreads, it will be
translated into  demand for such solutions from your suppliers who
will otherwise sit on the fence I suspect for a whole range of reasons
that I won't explore here.

- the development of Web-based solutions by suppliers, or (an
interesting possibility) add-on DIY developments by individual IM&T
departments to provide Web-enabled links to existing systems/data
warehouses.

And what does the GP need to access all this - a Web browser.  What?
you've got one already did I hear you say?  Hmmmm.  Bit different from
some of those other solutions we've heard a bit about.......

>There are all kinds of issues to
>consider when 'trading' information many of which I would have thought
>were independent of the technology.  EDI messaging has to do with
>exchanging structured information in such a form that it can be
>incorporated in the receiving system in a way that enables it to keep
>its original (concept plus context) meaning. 

Yes, but if you think about it carefully, many (most?) of those issues
are a result of the messaging/ information exhange paradigm.  If
you're actually looking at the remotely held information in situ, then
the remote system will provide the relevant context because it knows
it.  Context is then a presentation thing - how the information is
integrated from multiple sources, marked up, laid out  and presented
to you, what additional information is incorporated or accesible via
that page etc.  You've just got a transient window into that
information not your own permanent copy.  IMHO it's when you exchange
or "trade" a copy of the information that the issues bite you in the
bum.

> Am I missing something
>here?  How would that be achieved unless, for example, we had universal
>HTML record structures?

Well that's one approach.  There's an interim pragmatic approach that
says the current methods of storage of healthcare information are
determined by the suppliers of those systems anyway - very much a
proprietary thing, and it will be years before that changes, if at
all.  So HTML provides a means of presenting that information to you
in a nion-proprieary way as a Web page, albeit dynamically created.  I
can imagine an SMS system presenting you with a page of patient info
that might look different from the HBO system's presentation of the
equivalent information.  THis may or may not be a problem/issue - I've
not thought it through very hard.  On the other hand, I guess standard
HTML page layouts could be defined that all suppliers should conform
to when displaying particular types of information.

Where things do get interesting though is if we think about the
EDIFACT standard messages that have been developed, and break them
into two separate components - their content and their transport.  It
should be quite easy to translate an EDIFACT message's content into a
Web/HTML form (or set of forms).  As far as transport is concerned,
whereas EDIFACT messages are created off-line and dispatched by store
and forward over say X.400, a Web form is filled in in real time by
the user, click the submit button and it's dispatched by http to the
recipient back-end system (eg the hospital) where it can be dealt with
in real time (or batched at the back end) (what - no MHS charge ?!!).
So my view on this is the EDIFACT work has in fact defined for us the
standard content of Web forms that could be used as an alternative
(where appropriate and sensible) for EDI transactions - for example to
make a patient referral and do it by actually being online to the
hospital system so the hospital system can do the necessary field
validation against its own infornation there and then (and show you
the available options) , rather than you getting a message returned
next day saying field 12 was invalid please send it again.  

With this approach you've standardised on the EDIFACT content (the
useful bit) but translated into a universal referral Web form, and
dumped the transport side for http/WWW

>
>Not in any way decrying the potential value of this kind of development
>in web technology but trying to understand its potential..

Hope this helps to explain - if you're at Mednet this is a theme I'm
going to be addressing in a keynote speech and would welcome any
discussion then.  There will also be some rather interesting demos
I've put together to show the sort of things that are possible using
these technologies, to show it's not all hype and wishful thinking.
I'll be showing the demos at the InterSystems stand at Mednet.  Please
come along if you can.


---
Rob Tweed
IM&T Consulting Ltd; Health Web Services Ltd;
M/Gateway Developments Ltd

http://www.hwsl.co.uk/mgw
Tel: (+44) 181 540 1325
Fax: (+44) 181 715 4337
---


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

March 2024
October 2023
August 2023
June 2023
May 2023
February 2023
June 2022
October 2021
January 2021
October 2020
September 2020
August 2020
July 2020
June 2020
March 2020
January 2020
December 2019
September 2019
July 2019
June 2019
May 2019
March 2019
February 2019
January 2019
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
March 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
2006
2005
2004
2003
2002
2001
2000
1999
1998
1997
1996


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager