The Extract does need more work, although the concept is pretty simple (it is really just a set of request/response rules and wrappers for normal openEHR data). A review needs to be done with respect to EN13606-5, a service interface definition to see if we should use some of what is in there.
But for practical purposes, we developed an Extract XSD in Ocean that was used at the last MedInfo 2007, and I suggest that this could be used. It is not hard to work with, and some simple questions of identifier types (e.g. Oid versus Guid) were worked out in 2007. The XSD is on the page http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html . I have created a wiki page for the 2010 conference at http://www.openehr.org/wiki/display/resources/MedInfo+2010±+South+Africa so please feel free to use that to coordinate activities.
I have started a child page where we can start collecting some info
about who is interested in participating in the connect-a-thon (onsite
or offsite). We can then begin determining exactly what we will be
demoing.
The Extract does need more work, although the concept is pretty simple
(it is really just a set of request/response rules and wrappers for
normal openEHR data). A review needs to be done with respect to
EN13606-5, a service interface definition to see if we should use some
of what is in there.
If the XSD will be formalized, I will see that I build my services so
that the can use it. No problem. But we also need a WSDL or another form
of formalized API for the message-processes.
In this way, we can be sure that if we see OpenEHR-services, we know how
to get our data in there.
If this, also is done, I am happy to make my service to conform to that,
so that interoperability is a fact.
I understand that with respect to EN13606-5 (is it already formalized?)
things can change. But on the other hand, we can do with something we
can expect it will be.
I will wait on further instructions, and hope we are able to show some
really good things in september 2010.
We need a coordinator to arrange all necessary formats.
Who will volunteer?
But for practical purposes, we developed an Extract XSD in Ocean that was used at the last MedInfo 2007, and I suggest that this could be used. It is not hard to work with, and some simple questions of identifier types (e.g. Oid versus Guid) were worked out in 2007. The XSD is on the page <a class="moz-txt-link-freetext" href="[http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html](http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html)">[http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html](http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html)</a> . I have created a wiki page for the 2010 conference at <a class="moz-txt-link-freetext" href="[http://www.openehr.org/wiki/display/resources/MedInfo+2010+-+South+Africa](http://www.openehr.org/wiki/display/resources/MedInfo+2010+-+South+Africa)">[http://www.openehr.org/wiki/display/resources/MedInfo+2010+-+South+Africa](http://www.openehr.org/wiki/display/resources/MedInfo+2010+-+South+Africa)</a> so please feel free to use that to coordinate activities.<br> <br> - thomas beale<br>
Tom do you have a small sample XML from MedInfo 2007 that is valid for the extract xsd ? e.g. one patient with blood pressure ?
This project sounds very exciting but I wonder if the use of an EHR Extract will fire up sufficient clinical/managerial interest.
As an alternative how about considering a patient’s path from an Emergency visit, looking up/importing data from a GP-held summary (or even a Google Health summary), Tony’s Soap stuff then eventual discharge letter. Being able to do this seamlessly across different ‘vendors’ and platforms would be compelling, especially if the contents could be changed at the whim of one of us annoying clinicians e.g Revise an archetype by adding some new elements, rerun the pathway and see how each individual system should be able to handle the change, including those who do not have access to the newer archetype.
This could make use of the CKM ‘top 20 archetypes’ work’ (and anything else), which will be at the heart of almost all clinical communications - ADR, medication, Diagnosi, lab tests etc.
Or is this too adventurous…
Ian
Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll ian@mcmi.co.uk
This project sounds very exciting but I wonder if the use of an EHR Extract
will fire up sufficient clinical/managerial interest.
As an alternative how about considering a patient’s path from an Emergency
visit, looking up/importing data from a GP-held summary (or even a Google
Health summary), Tony’s Soap stuff then eventual discharge letter. Being
able to do this seamlessly across different ‘vendors’ and platforms would be
compelling, especially if the contents could be changed at the whim of one
of us annoying clinicians e.g Revise an archetype by adding some new
elements, rerun the pathway and see how each individual system should be
able to handle the change, including those who do not have access to the
newer archetype.
This could make use of the CKM ‘top 20 archetypes’ work’ (and anything
else), which will be at the heart of almost all clinical communications -
ADR, medication, Diagnosi, lab tests etc.
Or is this too adventurous…
Ian
Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll ian@mcmi.co.uk
does not seem to have any patient identifiers. Without the basic functionality of being able to even match a patient its hard to get the data into the system in the first place. I have several questions around the archetype identifiers when we get there.
I think we need a simple step by step test case which walks through the process and identifies what data is being sent where. The actual protocols are not important but the content and how patients, visits and clinical content is matched is important.
Tim
You kindly offered to help organise this, please let me know if I can
help in any way.
Shinji
You mentioned the abstract submission deadline of Sept 30th.
What do we need to prepare as a group to organise ahead of this date?
I agree with Ian that we should try to follow patient journey stuff, EM
Summary to SOAP note updated on discharge to EM Summary again.
This deadline should help us all focus efforts...
Kind Regards,
Tony
Dr. Tony Shannon
Consultant in Emergency Medicine, Leeds Teaching Hospitals
Clinical Lead, Clinical Content Service, NHS Connecting for Health
Chair, Clinical Review Board, openEHR Foundation
+44.789.988 5068 tony.shannon@nhs.net
I confirmed the instructions for authors of Medinfo 2010. http://medinfo2010.org/Instruction_for_authors.pdf
First of all, we have to decide the type of presentation. We can choice
papers, posters, scientific demonstrations, panels and pre-congress
tutorials and workshops.
I think *pre-congress tutorials and workshops and *scientific
demonstration will be suitable to present our discussion. or Panel?
Please advise me.
At the second, we have to fix the authors, presentors. Who will join?
In the mails so far, Rong Cheng, Ocean Informatics group and I will join
the medinfo2010. Tim will join online/offsite. Will your Opefera group
join?
Or a hopefully slightly more helpful reply might be:
- The blood-glucose-sample.xml is not a complete extract, it needs to
be encapsulated in a proper extract.
- The line <subject xsi:type="PARTY_SELF"/> says that the glucose
value belongs to the patient who's record the extract comes from (not
information about a relative etc. that might also be in the record).
- The patient record identity information should be in the enclosing
extract. In http://www.openehr.org/releases/1.0.2/its/XML-schema/Extract.xsd
I think it would be under <xs:complexType
name="EXTRACT_ENTITY_IDENTIFIER"> wich in turn refers to demographic
information that can be included in another part of the extract (or if
not present) can be requested separately as an extract. See http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_extract_im.pdf
I believe this would be easier for many to understand if there were
some COMPLETE extract instance examples (and extract requests)
available. (On an HL7 course I learnt that many/most developers prefer
first looking at HL7 instance examples instead of trying to understand
the underlying model. I think the same could apply to some openEHR
use-cases).
I think that you will be key in leading the charge to be sure that we
have the correct archetypes in place. Maybe even if they haven't all
passed review by then???
We at least need to have a MedInfo2010 Set defined. Probably no later
than 1 December. So we have the list prior to everyone going on the
holiday break. This will provide time for the various application
developers to do template building and testing. Maybe enough time for
CKM/ARB certification as well?
But of course this means that we also need to define the number of use
cases and number of patients we will be demoing.
Hi Erik and others,
I will provide an EHR_EXTRACT to the list as soon as possible. I have been
absolutely snowed under doing software releases and currently at an IHE
Australia connect-a-thon where I am using archetype models as the semantics
basis for transforming HL7 V2 messages to an IHE Medical Summary compliant
level 3 CDA and openEHR via the same template data document.
If I don't get one out by early next week please remind me.
In reply..
I am a believer in keeping things simple where possible.
My sense is that we can demostrate an impressive solution if we offer
support around a single/few patient journey(s) and a limited set of
archetypes.
Let me play devils advocate and suggest all we need to address for the
majority of this is just 2 overlapping groups of archetypes.
1) The Emergency Summary set (Top10) that Heather has been polling for
2) The SOAP note set
Note that these have significant overlap.
That journey could begin in any/many ways..
eg
1)
Newborn .. with a SOAP note
Home with a Summary note
2)
To the Primary Care doc.. with a new SOAP note
At end of visit.. an updated Summary
3)
To the ED/other Unit.. where we access the Summary
Then we add a new SOAP note
Then we update the Summary
4)..into old age..
When a Long Term condition requires more SOAP notes
and updates to the Summary
and so on and so on..
OK a very simplistic example, but I hope it illustrates a point.
If some think that its too broad then we could use a subset of that
journey..again only needing with SOAP and Summary.
The top 10 Summary drive has already begin the process of now starting
to explore 15/20 key archetypes, all of which selected can and will
provide the basis for the SOAP note too.
One point your question does raise is whether we are aiming for
archetypes that have more breadth or depth, or a mix in between.
I would be looking for the Medinfo demo set to provide *just enough*
(and no more than that) detail to get the demo across.
I would not expect us to have finalised the definitive archetypes for
Summary/SOAP by then. There will be never be "final" versions of any of
these anwway..always works in progress.
Thats useful.
Some other feedback from clinical colleagues would be useful on this.
Certainly the high level use cases you posted , ie Newborn and then 65yo
with Chronic Diseases should be useful.
The detailed candidate content posted up about these 2 I'm not so
concerned about directly replicating.. if we can tackle the archetypes
needed to do SOAP and Summary noting these can form the basis of the
material needed to support both journeys.
The top 10 Emergency Archetype work Heather is currently over seeing
will begin that. Not sure what timetable is realistic for broadening out
CKM input to cover the other material needed for SOAP, but Im sure it
will be months rather than weeks.
It may be that a few of us produce a candidate subset of archetypes
that can handle both SOAP and Summary for the Connectathon purposes
ahead of any ARB/CRB checks, given the time pressures you were
suggesting earlier. Dec 1 gives us about 12 weeks I guess.
My sense is there must be value in agreeing a small set of very basic
set of archetypes over the next weeks for these purposes if that helps
move forward the Connectathon..
Others may have a view on that? #Heather do you want to comment on this thanks..
Perhaps other can comment on the date time and technical issues for the
connectathon.
I've updated the wiki as we will be aiming to use Opereffa within the
Connectathon, Serefs time will likely be constrained but thankfully he
is certainly willing to try...
In addition to deciding on archetypes to use, I believe circulating a
couple of complete instance examples fairly soon (this week?) would be
very helpful in detecting differences in specification
interpretations. Having more than one archetype editor certainly
helped detect differences and ambiguities in other parts of the
specification earlier.
Things to include in the instance examples:
- EHR instance data constructed using comoposition archetypes with a
couple of nested entry archetypes
- Several versions within a versionied composition, both IMPORTED
_VERSIONs and ORIGINAL_VERSIONs
- Several "creating systems" producing version branches (and possibly a merge).
- Realistic demographic content including some example clinicians,
organisations and patients.
- Use of the "participations" attribute of EVENT_CONTEXT
(- Possibly also folders)
The examples do not right now need to use exactly the optimal
archetype set intended for the connectathon, we'll probably raise many
important implementation issues & discussions anyway.
Question: Is CONTRIBUTION information never sent explicitly between
systems, but only backward-referenced via AUDIT_DETAILS via the
"composer" attribute of COMPOSITION?
I'll have to admit I dont fully understand that question... not sure if
thats a good or bad thing ;o)
I am keen to help agree on a starter set of archetypes to use for the
demo, though I'm coming at this from purely clinical benefit and
communication grounds. ie what is the minimum patient journey we need to
show so that lay clinicians can look at that and say to themselves..
"Hmm, so thats what openEHR can do.. that looks useful".
Tim may be able to reply to your technical concerns..
I'll have to admit I dont fully understand that question... not sure if
thats a good or bad thing ;o)
I am keen to help agree on a starter set of archetypes to use for the
demo, though I'm coming at this from purely clinical benefit and
communication grounds. ie what is the minimum patient journey we need to
show so that lay clinicians can look at that and say to themselves..
"Hmm, so thats what openEHR can do.. that looks useful".
Thanks for this Tony. You did a great job of reading my mind.
It is my hope that you can get a group of clinicians to add to the wiki
(maybe create a new page?) to develop this journey.
Then we'll be in a better position to define the operational aspects of
the event.
Tim may be able to reply to your technical concerns..
To respond to Erik. I, for one, will not be prepared to exchange any
instances until Jan/Feb time frame.
I think we should set a goal to do actual testing of instance data
exchange for 1 March, 2010. That still leaves 6 months for any fine
tuning; if needed.
