This discussion document is produced by UCL (CHIME) to highlight issues that have arisen when designing a Demographics Service component. This service component will need to conform to the openEHR demographics package and be able to support the requirements of live demonstrator sites in north London. Any feedback and comments are welcome.
Yin Su Lim wrote:
This discussion document is produced by UCL (CHIME) to highlight issues that have arisen when designing a Demographics Service component. This service component will need to conform to the openEHR demographics package and be able to support the requirements of live demonstrator sites in north London. Any feedback and comments are welcome.
This is a _tantalising_ question - that I've ruminated on for some time.
First it is not clear why Demographics should be separated out like this from the entire record - it just introduces potential inconsistency due to replication issues or worse mis-identification of a patient.
From an evidence-based perspective, it might be best to send and
receive a "sealed network packet" of as much as the patient record as bandwidth permits:
That could mean the entire text data - leaving larger payloads such as exam-data/imaging/traces etc to be requested on demand.
The receiving medic would then be able to make any decisions on the basis of the best available evidence at that particular time - using the traditional document metaphor. Of course the onus is on client-side to
make all evidential aspect of that document visible during any decision
making [no mean task].
But surely in an active clinical community the entire patient record cannot be locked out of use while one participant is working on it.
Traditional database/directory locking works against rather than for the
collaborative process IMHO. Sure participants need to be aware of each
others concurrent activity on the same record but they must be given both (1) the means to communicate with each other to decide if either
should go first (2) some convenient means to resolve conflicts that would otherwise arise in the patient record due to their individual asynchronous submissions. This is _not_ rollback but is instead a kind of roll-forward and again the emphasis would be on a smart client
(able to coherently explain conflicts and choices to resolve them
at the point of resubmission) - rather than smart server.
The flavor should be that of a Wiki while the
overall philosophy should be that of evidential audit/logging: who saw what and what they did when they saw it - for medico-legal purposes.
Here the entire patient record would be archetyped as
a single document in which Demographics was a self-contained subsection.
If you really needed to you could just replicate that already archetype
sub-section on a Demographics Server - but that should be a read-only
copy - the mastercopy being of course that in the full record.
Something like a versioning XML server
(xmlDB,Xindice,OracleXML DB) might be the way to go.
Just my 2 penceworth
I couldn't agree more. In fact, I recently suggested that medical records
be viewed as having dynamic and static components that should be handled
differently in an RFI response to HHS. My feeling is that things like DOB,
sex, and race do not change and can be stored as such. Other data, such as
name, address, phone, and insurance change infrequently, and can be updated
often. Dynamic information like blood pressure and heart rate change
instantaneously, presenting different storage challenges.
In order to make an accurate record of a patient encounter, these elements
must be combined into a "snapshot" for that time and place. The EMR should
be able to gather these components from several different places to create
that snapshot of the patient. The components themselves can be stored in a
variety of locations, determined by the nature of the data and the optimum
facility for processing them. Appropriate security data may vary by data
type.
Ed Ermini MD
Hi All,
Demographics (characteristics of a population) is one element of a larger more complex
problem which may be labeled 'Patient Categories and Classifications', or simply
'Patient Boxes'. Conceptualizing the postal annex analogy, the interesting part comes when
the available information is processed and placed into a designated box.
All those Patients living at some time within 25 miles of a known toxic waste dump
(important because the Cancer Death Rate spikes in this area) can be placed in an
appropriately labeled box. All those former military personnel who served in the first gulf war
go in another box. All those who received surgical care at a hospital identified with MRSA
into another box, or a box just for that hospital.
How about people who were employed in areas that later were identified as being life-shortening.
Pick a job site or a residential location (data supplied upon request). Or perhaps current
agriculture workers exposed to chemicals.
BTW: Try obtaining a complete medical record for a Patient from their branch of the
military.
A 'Demographics Service component' is an interesting project but my hunch is that my
HMO has not signed onto it.
A 'record' transmitted to a local or remote Practitioner should comply with a set of
'necessary' and 'sufficient' tests so that the recipient does not have to dig though
unrelated and inappropriate data, and the Patient is permitted to open the Kimono
far enough to obtain needed services.
The 'all-or-nothing' approach works where all data is relevant and where little data is
available. An 80 year old Patient may have suffient data to derail the practitioner and
deflect focus from currently needed treatment.
There are 'levels' of records and within levels there may be varying needs for different
Practitioners. What is 'necessary' and 'sufficient' for each Practitioner? We may be
talking about multiple records, e.g., my Internal Medicine Practitioner wanted one set
of information, the Surgeon wanted another.
Regards!
-Thomas Clark
Gavin Brelstaff wrote:
Hi,
Gavin Brelstaff wrote:
> First it is not clear why Demographics should be separated out like
> this from the entire record - it just introduces potential
> inconsistency due to replication issues or worse mis-identification of
> a patient.
I agree.
In my opinion, the whole EHR should be stored centrally somewhere.
Of course, it may be replicated regularly etc.
> From an evidence-based perspective, it might be best to send and
> receive a "sealed network packet" of as much as the patient record as
> bandwidth permits:
> That could mean the entire text data - leaving larger payloads such as
> exam-data/imaging/traces etc to be requested on demand.
[..]
Good idea! May be not as much as bandwidth permits, but just that extract
of information which a special kind of Medical Practitioner (MP) needs.
> But surely in an active clinical community the entire patient record
> cannot be locked out of use while one participant is working on it.
[..]
What about optimistic locking? If several MPs get different parts
(extracts) of an EHR, then at checkin their data do not necessarily
have to conflict.
> The flavor should be that of a Wiki while the
> overall philosophy should be that of evidential audit/logging: who saw
> what and what they did when they saw it - for medico-legal purposes.
I agree.
> Here the entire patient record would be archetyped as
> a single document in which Demographics was a self-contained subsection.
> If you really needed to you could just replicate that already archetype
> sub-section on a Demographics Server - but that should be a read-only
> copy - the mastercopy being of course that in the full record.
>
> Something like a versioning XML server
> (xmlDB,Xindice,OracleXML DB) might be the way to go.
I agree.
[..]
A 'Demographics Service component' is an interesting project but my
hunch is that my
HMO has not signed onto it.
I think this is just a question of physical distribution, not of the
logical "inside" architecture of a software system (or component).
In my opinion, every EHR system should be able to send extracts of an
EHR to another system, may it be demographic information or others.
So, one could set up a physical box responsible for sending
demographics only, or images only etc. But the software running on
those boxes can be a general one, only that it once creates an EHR
extract with demographic-, and in the other case with imaging
information.
There are 'levels' of records and within levels there may be varying
needs for different
Practitioners. What is 'necessary' and 'sufficient' for each
Practitioner? We may be
talking about multiple records, e.g., my Internal Medicine Practitioner
wanted one set
of information, the Surgeon wanted another.
This is a very good idea. I didn't think about it this way before. An
EHR software solution could come with several default EHR extract
models -- comparable to the "Data Transfer Object" (DTO) pattern of
Martin Fowler: one DTO model for administrative/demographic information,
another for an Internal Medicine Practitioner and so on.
Of course, the software system needs to provide the necessary
"Translator" models as well. These are responsible for copying data
from the domain model to a DTO and vice versa.
If the Medical Doctors in a certain region want their own special
EHR extract models, they can just create them (together with the
corresponding translator models) on their systems. As long as both
communication partners (software systems) know how to translate a
certain model, there shouldn't be a problem.
And, of course, the data should preferrably be sent in XML format, may
it be the Clinical Document Architecture (CDA) or, even better, the
free Healthcare Xchange Protocol (HXP).
Just some ideas,
Christian
Christine and Gavin
Some misunderstandings appear to have arisen. As all EHRs are composed of compositions - it is only necessary to lock a composition for update - and that will be usurped anyway by the new version.
Demographics are completely separated out - this is a design feature that has been there for some time and relates to legislation in some jurisdictions (no identifying information in the clinical data store) and does aid security.
Further, it makes merging of EHRs very straight forward and allows for different demographic identification at different sites - without leading to conflict.
I think you will come to see the utility of this approach.
Extracts are for moving information from one EHR store to another - not for accessing the EHR - this is done directly with the server - and the demographics can be handled as you wish behind the scenes.
Archetypes are for discreet, complete reusable concepts - it is possible to archetype the different RM classes - but section archetypes will not include entry archetypes - rather reference them. The 'chaining' of archetypes into a composition is done at runtime using 'templates'. These have not been formalised as yet - but I include an experimental template in XML (we have a shared tool to do this with ADL soon) to give you the idea.
The sort of XML this might generate for a BP of 120/80 measured with a wide cuff, an oral temperature of 36.5 C and pulse with rythm - for your information - is also included. There are 4 archetypes involved - one for the section - vital signs, one for BP, one for Pulse and one for Temperature. The template selects those aspects of these concepts that are required for recording vital signs, and how they will be organised. The fact that the BP is part of vital signs does not alter its meaning in any way.
The XML schema for openEHR data is not yet finalised, but will be a single schema for all shared information. At Ocean we optimise this somewhat for internal presistence - but the in memory representation is always the same and based on the RM.
Just to reinforce - these artefacts are not produced according to an agreed openEHR specification - and the standard form of templates will not be XML as in this example - though you can clearly do as you wish locally (templates do not alter semantics).
I hope this is helpful.
Cheers, Sam
Christian Heller wrote:
(attachments)
Vital_signs_openEHR.xml (11.3 KB)
Vital_signs.template (1.05 KB)
The EHR is rather a unique document and a layered approach is necessary as
old data must never be altered - may not necessarily be accessible but must
never be altered. Errors can be corrected but the error must remain totally
accessible in the manner it was presented to the clinician when it was
relied upon - eg clinical results, medications.
The concept of layering new information on old is important.
There does have to be lock outs or transaction controls when new data is
being entered in but there is no need for old material (old may be seconds
of course)to be locked out cause it can't or shouldn't be changed.
If two doctors are entering elements of say a discharge summary then one
cannot edit while another is adding - it needs a message indicating someone
else is working on the current document and wait. It is more complex than
that but the basic principle applies old data never changes even old
addresses must stay.
Legally it is important to be able to reproduce exactly the circumstances
that the computer presented to the clinician at any point in time for
inquests, litigation etc.
We are dealing with these issues today with our CIS and it is a challenge.
David Evans
Brisbane Australia
Please once more your attention:
There is no way, except by use of the OID, for an automated process, to find
out which kind of identifier is presented in the extension.
(As described in TS14796, the assigningAuthority may not be used by an
automated process, and the assigningAuthority says nothing about the kind of
II, but only about the name of the Authority, which often is a government
institution, a healthcareprovider-name or a company-name.)
The OID heavily relies on services which are not yet defined or implemented in
many environments in the (Dutch) field.
Therefore, the OID is at this moment not useable for me, and I doubt if it
will be coming few years in the Netherlands. What is also important, is that
the OID often only will be resolvable when there is a connection to the
overall Internet, which not always may be the case.
Therefor, I would welcome if there would be a Qualifier in the II-object,
which defines what kind of identifier is presented in the II-object. This
qualifier could use a not too long list, for example
- local system ID
- insurance number
- social security number
- ....
This would be a blessing for the project on which I am working.
How can I handle this best and efficient?
Are there any thoughts about this?
Thanks
Bert Verhees
One more remark/question:
Is there an OID which can be used if there is no OID known, f.e. 0.0.0.0.0?
I ask this because OID is a mandatory field
Thanks
Bert Verhees
Allow me a ignorant question
Is tehere a place where I can download sourcecode from GPIC implementation, to
learn from.
The programming language is not important.
Thanks
Bert Verhees
Hi David,
Significant problem! However, software configuration management has solved this
before. In the Legal or secure OS environments the contributions of individuals are
in fact part of the record even through the 'end-game' is an update that merges the
contributions of all, e.g., a composite record.
It is critical that 'information' is not lost nor corrupted. Efforts to 'crunch' multiple
records into a satisfactory record usually fail this requirement at some point.
A reasonable objective is to permit multiple Practitioners to enter information
simultaneously, maintain original context and content, build a composite record
that is compatible with the target record-handling system, and support 100%
re-assembly of all sources of information. A 'build-and-submit' or 'interactive-entry'
architecture can yield multiple 'composite' records that may also be linked by one
or more events, e.g., surgery and lab work.
It may also be necessary to declare a higher-order event (in a record) to which
subsequent events can be linked (extra-record, meaning the event can transcend
a collection of records, e.g., multiple contacts-same cause).
Information organization is a virtue; lack of it may well impact information retrieval.
Try coordinating the activities and results of 20+ Software Engineers working on a
release. Things happen in parallel. The Legal environment in particular requires
reconstruction.
Regards!
-Thomas Clark
Bigpond wrote:
The EHR is rather a unique document and a layered approach is necessary as
old data must never be altered - may not necessarily be accessible but must
never be altered. Errors can be corrected but the error must remain totally
accessible in the manner it was presented to the clinician when it was
relied upon - eg clinical results, medications.
That is not feasible as it would amount to taking physical
pictures of the screen as it looked when displayed. And even
this would only prove what the user *might have seen had she
tried* - certainly not what she *saw*.
Karsten
Karsten
You will see from the attestation class that it is possible to add an image with a digital signature - allowing compositions to be pixelmaps for legal purposes if required.
Cheers,
Sam Heard
"That is not feasible"
And that's the problem that will keep the technical people in money for
years to come. Not only must it be feasible it will be demanded by judges
and courts if the EHR is to ever be truly adopted. Even now we have rules
that all e-mails where a decision is made must be printed out!
The paperless world has never been to court.
It is feasible of course but complex. Flags are set when pages are viewed,
there are intricate audit trails (terabytes). The fact that no one is doing
it yet is that the litigation costs haven't risen high enough to balance the
need to do it. Once a few specialists are sued for activities that can not
be supported by the record and they known they were innocent then we will
see some very interesting changes, either a reappearance of paper records
(personal) or a new paradigm of image capture. IMHO of course.
David
You speak much sense!!
"The Legal environment in particular requires reconstruction."
Oh that was the best one I heard today - it's in the order of when the warp
drive emerges.
Need to think more on your wise thoughts though.
David
Hello David and Thomas,
You said:
You speak much sense!!
"The Legal environment in particular requires reconstruction."
When you combine these ideas of "Sense Making" and "Reconstructing the legal
environment's relationships to medical communities of _EHR practice" we
tickle the need for some common upper ontology for the domains of governance
which includes the process by which the legal environments are created and
maintained in various countries.
Several of us involved in a US NHIN_EHR Request for Information process have
begun muddling the question of governance in standards bodies such as OASIS
and considering the processes by which XML evolved under Jon Bosak and
others a decade ago as the basis for building some US Natl Health
Info/Knowledge Networks to support standards for _EHR deployment and use.
So an intenational awareness is essential, but how far has the openEHR
community explored these dynamic issues? And how are the relationships being
expressed?
Bob
Sam,
You will see from the attestation class that it is possible to add an
image with a digital signature - allowing compositions to be pixelmaps
for legal purposes if required.
Well, surely it's technically possible to track images of what
was sent to the screen for display. But does that help any ?
They screen may have been obscured for some reason or other at
several layers (software, hardware, physical world).
Karsten
"That is not feasible"
And that's the problem that will keep the technical people in money for
years to come.
I am not a technical person per se. I am an clinician.
Not only must it be feasible it will be demanded by judges
and courts
Surely, courts and judges have been known to demand and
accepts proofs that aren't proofs before. They'll learn, too,
what things need to be taken to mean.
if the EHR is to ever be truly adopted.
Too pessimistic, IMO.
Even now we have rules
that all e-mails where a decision is made must be printed out!
Which is akin to photographing every screen you view.
The paperless world has never been to court.
In a court one not always has to provide a waterproof trail of
evidence. There is "substantial evidence" (is that what it's
called ?). And there is "demonstration of due course" which
adds a lot of weight to what otherwise are simple assertions.
It is feasible of course but complex. Flags are set when pages are viewed,
Those flags do not document what you want them to document.
Such a flag only documents that it was set. Everything else is
"due course". Eg. if the flag is set "it is reasonable to
assume" that it was set by the software the doctor claims to
have used. Also "it is reasonable to assume" that the doctor
thus "saw" what that program would display in conjunction with
that flag being set. No hard proof there.
there are intricate audit trails (terabytes). The fact that no one is doing it yet
Why do you think this is a fact ?
Karsten
Life is simple.
Once we physicians know what to ask and why.
Gerard
-- <private> --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
+31 252 544896
+31 654 792800
"That is not feasible"
And that's the problem that will keep the technical people in
money for years to come.
$$$ Cheers $$$ 
Not only must it be feasible it will be demanded by judges and
courts if the EHR is to ever be truly adopted. Even now we have
rules that all e-mails where a decision is made must be printed
out! The paperless world has never been to court.
It is, but a matter of time. In this case, may take varying
amount of time in different countries, but then technology will
finally prevail. Do you recall a few decades ago when ball
point pens first made an appearance in the market ? It took
some time for banks and courts to accept documents signed in
ball pens ! But then, that was a relatively minor thing when
compared with a digital transition. And we have all forgotten !
The main issue here is varification of authenticity of digital
data entry. There must be some mechanism to ensure that every
entry placed in the EHR must be authenticated by the signitory,
even if the entry is made by a secretary, DEO or transcription-
ist. Once a fail proof method is evolved, the legal process
would gradually yeild. The value of the signed hard copy is
aithenticity, not content. It is this issue that we need to
address.
It is feasible of course but complex.
Authentication must be ensured in spite of the complexity.
There is no alternate recourse.
Flags are set when pages are viewed, there are intricate audit
trails (terabytes).
Audit trails of visits are only to ensure read access by
authorised agencies. What is more important is 'write access'
authentication, by best means as commensurate with available
technology. No doctor should be in a position to deny that
'this medicine was not prescribed by me' or 'this is not my
report' at any stage.
The fact that no one is doing it yet is that the litigation
costs haven't risen high enough to balance the need to do it.
Once a few specialists are sued for activities that can not be
supported by the record and they known they were innocent then
we will see some very interesting changes, either a
reappearance of paper records (personal) or a new paradigm of
image capture. IMHO of course.
It would be inappropriate to wait for litigation processes to
bring in the change. The thought process would have to be built
in right from scratch, and refined as technology advances. For
a start we could start with password/ paraphrase protected
write access, or GPG/ PGP or maybe thumb imprint ...
But then this is an important issue, and you just can't bypass
the Law anywhere ...
Dr USM Bish
Bangalore