CRUD Restlet

[Bert Verhees]

I was looking at EHRScape, I should have posted this question there, but 
the Community-page does not show any communication-means, only adds.

And maybe the question is also generic and are more people thinking 
about this.

I am wondering about the HTTP-errors, they seem to be used for 
communicating application-errors.
I think this could be an error.

For example, if you look at the:DELETE /demographics/party/{partyId}

It can return a 404 with explanation: 404 Not found - the specified 
party was not found (DEMO-6021).

I think this is possible wrong, because on HTTP-level the call was an 
success, and should therefor return 200, meaning, the request is 
received and understood, and processed.
In the return-message it should IMHO, if necessary the result and 
error-message on application level.

Someone thoughts about this?

Thanks
Bert
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150116/b31c9104/attachment.html>

Upcoming EHR procurment in Sweden

[Erik Sundvall]

Hi!

I just want to notify EHR vendors and other interested parties that there
is now a (from Swedish perspective) big procurement/buying process
starting. It is the three largest healthcare regions in Sweden covering 5
million of Sweden's 9 million inhabitants, it is the regions containing
Sweden's largest cities Stockholm (Stockholms l?ns landsting), Gothenburg
(V?stra G?talandsregionen) and Malm? (Region Sk?ne) that together will
attempt to get a good deal for a new (probably) all comprehensive
EHR/Health-IT-system covering for example both primary and secondary care.
I hear rumors that the deal or procurement might be open for other Swedish
regions to join.

Personally I hope that whoever wins this battle will be open to using real
open/shared detailed clinical modeling via something like CIMI, ISO13606 or
openEHR and open/shared clinical query capabilities comparable to AQL, and
a way to share decision support rules between systems. Either by using some
powerful enough RM+AM system internally or by creating reusable (not too
manually resource demanding) conversion mechanisms between internal
models/queries/rules and international shared models/queries/rules.

If the procurement organisation sees enough value in such shared
models/queries/rules or not, I guess is still an open question that
probably will be affected by how different actors present the value of this
compared to potential benefits of proprietary such models and systems.

A press release in Swedish with some names and contact information is
available at
http://www.mynewsdesk.com/se/region_skane/pressreleases/nu-laeggs-grunden-foer-ett-gemensamt-informationssystem-foer-sjukvaarden-1105218
(and
via a non-perfect Google translation
<https://translate.google.com/translate?sl=sv&tl=en&js=y&prev=_t&hl=sv&ie=UTF-8&u=http%3A%2F%2Fwww.mynewsdesk.com%2Fse%2Fregion_skane%2Fpressreleases%2Fnu-laeggs-grunden-foer-ett-gemensamt-informationssystem-foer-sjukvaarden-1105218&edit-text=&act=url>
)

According to an article at...
http://computersweden.idg.se/2.2683/1.604479/nu-lyfter-de-tre-stora-vardregionerna-it-miljon
(and
via a non-perfect Google translation
<https://translate.google.com/translate?hl=sv&sl=sv&tl=en&u=http%3A%2F%2Fcomputersweden.idg.se%2F2.2683%2F1.604479%2Fnu-lyfter-de-tre-stora-vardregionerna-it-miljon>
)
...there will first be a requirements gathering process (around one year?)
and then procurement follows.The article states that they are looking a bit
at Denmark and Finland that recently have bought new systems.

One could hope that they will also have a look at some recent Norwegian
"Nasjonal IKT" developments involving open specifications and archetypes,
e.g. http://arketyper.no/ckm/. I guess a similar procurement battle is
going on in (or coming to) Norway.

It is worth noting that Sweden is a member of IHTSDO and that Snomed CT has
been translated and is available in Swedish. I hope vendors will show
proper capabilities to make use of powerful terminology systems and
ontologies and that requirement gathering staff will describe what they
want to use the systems for now and in the future.

As always the requirements gathering is likely to be influenced by what is
already available on the market and by marketing actions of involved
players.

This message contains no secrets so feel free to forward it to other
persons and organisations.

Good luck to both vendors and requirement gathering staff!

Best regards,
Erik Sundvall
Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or
010-1036252 in Sweden)
Region ?sterg?tland: erik.sundvall at regionostergotland.se (previously lio.se
) http://www.regionostergotland.se/cmit/
Link?ping University: erik.sundvall at liu.se, http://www.imt.liu.se/~erisu/

P.s. to openEHR vendors:
If...
you in a connectathon-like demo can demonstrate real interoperabilty
between several openEHR-capable systems and that complete EHR content for
patients, decision rules, archetypes, templates etc can be moved from one
system to several competing (and/or open source) systems without too much
hassle
...then...
the procurement argument of "avoiding vendor lock-in" will be more
interesting. Such a demo would be interesting for some of us working in
other Swedish regions too.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150116/5db71c4b/attachment-0001.html>

AQL with Demographics

[Karsten Hilbert]

On Fri, Jan 16, 2015 at 12:44:24AM +, Thomas Beale wrote:

> >the first question is: is the patient sex and location stored in the EHR
> >in the system? If so, it's just standard EHR-based query.
> >
> >I'm assuming that the location / address is not however. So a normal query
> >can be written to do everything except the 'living in Alkmaar' bit.

That's exactly the boundary between systems "built for"
medical care vs "built for" epidemiology. Both may have
requirements that are contrary to each other, such as this:

> >That last item will need a traversal of the reference
> >PARTY_PROXY.external_ref 
> >,
> >if you have it set. But you might not have it set - we don't in most of
> >our systems, due to privacy / security.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

AQL with Demographics

[Thomas Beale]

On 15/01/2015 09:28, Alessandro Torrisi wrote:
> Hello,
>
> did any off you thought about how a query should look like suppose I 
> want such like this :
>
> "Give me all *female* patients living in *Paris *and with *no 
> allergies* and a *the last labresult of type Kreatine is < 20 but 
> within a year*"
>
> The hardest part is to combine the demographic information with the 
> medical information. Should you be able to do it with AQL?
>

An earlier private response to Alessandro before he posted:

> the first question is: is the patient sex and location stored in the 
> EHR in the system? If so, it's just standard EHR-based query.
>
> I'm assuming that the location / address is not however. So a normal 
> query can be written to do everything except the 'living in Alkmaar' bit.
>
> That last item will need a traversal of the reference 
> PARTY_PROXY.external_ref 
> <http://www.openehr.org/local/releases/1.0.1/uml/Browsable/_9_5_1_76d0249_1140169202660_257304_813Report.html>,
>  
> if you have it set. But you might not have it set - we don't in most 
> of our systems, due to privacy / security. In our Ocean system we 
> would deal with this bit of the query by a special query that takes 
> the EHR id and then runs it through the EHR Index service, to convert 
> EHR ids to subject ids, and then a query has to be done on those 
> (something like another AQL query) to get the ones who have an Alkmaar 
> postcode or however you test that.
>
> This clearly isn't well defined yet in a standard way.

It might be interesting to find out what other implementers are doing.

- thomas

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150116/317455a1/attachment.html>