HSSP RLUS/EIS Meeting Minutes August 09, 2007
Brad Lund – Intel - Facilitator
Kristina Kermanshahche – Intel
Lee Collar – Oracle
Alean Kirnak – Software Partners
Don Jorgenson – Eclipse
John Farmer - Care Data Systems
Joe Natoli - Intel
John Koish - VA
David Sheilds – Software Partners
Ian Sthal – Software Partners
Alan Honey – KP
Bo Dagnal - VA
Alan H.: Look at submission to see if there are any gaps.
Joe N.: Develop Spreadsheet of interfaces with participants across top and interfaces on bottom - DONE rdJoe N: Joe to facilitate meeting on the 23
Discussion: Software Partners Document discussion - Alean K.
Patient ID Service: Mapping of SWP’s interfaces to what Intel proposed isvery close - Where it diverges a bit is ListLinked_Entity; also PDQ query’s might be an interesting
mapping to look at. Also PIX Notify could be very much line one of the interfaces we have.
John F: think this is easy to understand using the terms chosen
Joe N: Agrees terms are good but using what mechanisms
John F. Could have explicit terminology; for the sake of recognizeability use HL7 terms where applicable in operation names. The OMG PIDF Spec is a good spec to look at to draw from vendor implementation.
John: It is important that they see operation and argument names and know what their looking at.
Joe N: Names came from SFM, if we change names do we have to do something to the SFM? Let’s do what we can to make naming understandable – but the scope of EIS is
not just people.
John F: We want to look at all of this to make sure we have not over looked any interfaces
stThe Guiding Principals located on WIKI – 1 Principal optional parameters should be
document data as payloads – if we went with most the powerful expression we would choose HL7 V3 xml or even EDI documents.
Joe N: RFP says we need one that is platform independent and one that is platform specific it is the platform specific one where we can choose XML like XML in CDA.
John K: Suggest another set of use cases – look at what the VA is doing – Can Bo show a
Bo: VA moving toward s a patient centric PHR and EHR to be interoperable with external partners – all SOA directed. The Clinical Data Service, used to retrieve update records management still needs to be done. The Personal Service Identification Management – does all patient id management functions = another XML based VHAIM information model – and automated way to transform data into HL7 data.
John K: One thing – We should create an excel spreadsheet that has a waterfall list of stuff we are trying to solve – a check list as an internal mapping
John F: Spreadsheet with participants across top and interfaces on bottom – Take the
“EIS Ideas doc” and put it in column 1…
Joe N: Yep also map SFMs submit to list server
Alena K: Add column for IHE
Joe N: Add Intel and SFM, Alean SW, IHE and OMG and other companies
Bo: Will add VA as will Oracle and Caredata and provide areas for Comments – how it
may differ or other issues
Comments from last meeting
Joe N: Comments from last meeting – Took out all xml and used Visio – also transferred
stuff from word document into Visio.
Joe N: Added a reason code to all operations - In the data type = described as a complex struct and also provided separate version interface. As we move forward Joe will update the UML Document
For RLUS – it is similar to EIS but slight differences – operation name are quite similar
Alean K: Adding a parm to add a version for masking – there are specific making
algorithm issues. Maybe there is some special issue are masking?
Kristina: Do you think it varies by call or configuration setup by EIS or the installation itself?
Alean K: Need to know why it was version in the first place – did the app do it or did a
person do it?
Joe N: From discussion last week - he accommodated for this very issue
John F: Need to support both input control data i.e. policy specifier and output logical exception information i.e. register someone who exists.
Ocean Informatics Document discussion – Thomas Beale
Documents are located at: http://hssp-rlus-
NOTE: Thomas did not make this week’s call but did supply the following information
Apologies, I just realised I misread the date list and missed 9 August. To be honest - I think biweekly meetings would be better - what do others think?
I also will proably not be on the 16 Aug call and I guess not the following 2 either, because 10AM Pacific time is about 3 am for me while I am in Australia for MedInfo (next 3 weeks). Although, with jetlag, there is a small possibility that I will actually be awake at 3am Aus time on the 16th.
I will try to cover some things as best as possible by circulating material....
; there are quite a lot of corrections I would suggest to the RLUS SFM - if I can
have the Word version of the current draft, I will mark it up and circulate. Prior to
doing so, issues that I noticed include:
o EHR id needs to be distinguished from patient id, and both need to be
usable as keys to get records/extracts. This is because (as we all know),
patients routinely get multiple EHRs/EMRs created for them, especially in
o versioning is not adequately described / accounted for
o there are problems in the Preconditions of quite a lot of functions, for
example, 5.1.1 - Create an RLUS Entry - the 2nd 'precondition' is not a
precondition but a business requirement. A precondition is something
formal that can be tested by a caller in advance of making a call and
relates to the object being called (in this case, service interface). There are
other redundant preconditions that can be removed. THere are also some
unnecessary Exception consitions like "inputs are not valid" - this is
always true in a model of functions that supports preconditions -
precondition violations are always an exception. None of the
'preconditions' for 5.2.2 are actually that - they are business requirements,
or preconditions of the whole of RLUS being possible, but not of
o I think that quite a few of the 'Aspects left to RFP submitters' could simply
be removed, since they don't say anything useful, e.g. in 5.1.1 and 5.1.2.
; the semantics of the openEHR EHR Extract model - which should act as a cross-check on any functional interface we develop. The service interface implied by this document is a coarse-grained document-oriented interface like the one we are contemplating. For those that have the time, you might like to look at the use cases - these are easy enough to understand. Do we have a supported list of business use cases yet? I am sure that some of these will overlap with Alean's. The UML model may not be obvious on first take, so here are some hopefully useful hints:
o in fig 5, a general structural approach for requests and replies is proposed.
This may be useful in RLUS.
o in fig 6, you can see 2 ways of specifying what content to retrieve:
; using queries (here called 'criteria' in class EXTRACT_SPEC)
; using a MANIFEST, i.e. a list of identified items. Here, a
'manifest' consists of ENTITY_MANIFESTs, each of which
corresponds to a single 'entity', usually a patient. So this kind of
Extract can request and return data for multiple patients, which is
very common in batch lab result sends.
; the EXTRACT_VERSION_SPEC also indicates which versions to
return of the matched items.
o there are other flags in EXTRACT_SPEC, to do with link following,
including 'directories' (a CEN EN13606 concept) and so on.
o there are quite a lot of other issues that this model considers, may not yet
solved. I think the same issues will occur in RLUS.
; the Archetype Query Language. In general languages like this will be needed, and I expect most of them will look like Xpath, Xquery or some variant. AQL is being presented in MedInfo this week. This language is also being submitted to openEHR, and is as far as we know, the first portable 'semantic' query language, i.e. queries are written against the logical information model and archetypes, not the concrete database schema. My main point here is that I don't think simplistic structural models of queries will do for this exercise; instead, the model for queries needs to be a parsable language field, with the alternative being something very simple, such as a list of item / document ids.
To give an idea of AQL:
Get the number of all patients with diabetes who have HbA1c results greater than 7.0 in
last 12 months.
SELECT COUNT(e/ehr_id) FROM EHR e CONTAINS (COMPOSITION c [openEHR-EHR-COMPOSITION.problem_list.v1] CONTAINS EVALUATION e [openEHR-EHR-EVALUATION.problem-diagnosis.v1] AND COMPOSITION c1 [openEHR-EHR-COMPOSITION.report.v1]
CONTAINS OBSERVATION o [openEHR-EHR-OBSERVATION.laboratory-hba1c.v1]) WHERE e/data/items[at0002.1]/value/value=’diabetes mellitus’ AND c1/context/other_context/items[at0006]/items[at0013]/value>$today-P1Y AND o/data/events[at0002]/data/items[at0013.1]/value >7/100
Get all HbA1c reports that have been done in the last 12 months for a specific patient. SELECT c FROM EHR e[ehr_id=$ehrId] CONTAINS COMPOSITION c [openEHR-EHR-COMPOSITION.report.v1] CONTAINS OBSERVATION o [openEHR-EHR-OBSERVATION.laboratory-hba1c.v1] WHERE c/context/other_context[at0001]/items[at0006]/items[at0013]/value > $today-1PY
Show me a patient’s current medication list
SELECT c FROM EHR e[ehr_id=$ehrId] CONTAINS COMPOSITION c [openEHR-EHR-COMPOSITION.medication_list.v1]
Everyone will have some kind of querying approach that returns documents or parts thereof. We need to accommodate these languages, and also consider whether we will allow return values of 'less than a document', which I think we kind of vetoed for version 1 of this exercise in the Seattle discussion....but it is always wise to think ahead...