DOC

Agenda - Wikispaces

By Joel Russell,2014-11-28 12:44
5 views 0
Agenda - Wikispaces

HSSP RLUS/EIS Meeting Minutes August 09, 2007

Attendance:

    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

    ===============================================================

    ARs:

    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

    presentation

    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 docand 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

General:

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-

    rfpsubmission.wikispaces.com/Technical+Documentation

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

    large organisations.

    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

    particular functions.

    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...

regards,

- thomas

=========================================================================

Report this document

For any questions or suggestions please email
cust-service@docsford.com