Not that I understand much of this, but its interesting. https://en.wikipedia.org/wiki/MUMPS
I think the issue is that in a large hospital people can be accessing many complex individual health records at one time, but queries across records aren't that important. On Thu, Nov 30, 2017 at 5:06 PM, Nikhil Dhamapurkar < nikhil.dhamapur...@healthengine.com.au> wrote: > Thanks for your responses, Currently speed is not of much concern but its > worth noting the elastic search example for future. > > Steve Good to know you work on Apache ISIS will check on Shiro > authentication, will get in touch if we are looking for help in Apache ISIS. > > Regards > Nikhil > > From: Rade, Joerg / Kuehne + Nagel / Ham GI-DP > Sent: 29 November 2017 18:08 > To: users@isis.apache.org > Subject: AW: Accessing confidential data - 2 step authentication support > > Hi down there! > > Erik de Hair has implemented an isis-module using Elastic Search [1]. > > Probably worth a look if speed matters. > > HTH -j > [1] https://github.com/erikdehair/isis-module-elasticsearch > > -----Ursprüngliche Nachricht----- > Von: Stephen Cameron [mailto:steve.cameron...@gmail.com] > Gesendet: Mittwoch, 29. November 2017 12:37 > An: users@isis.apache.org > Betreff: Re: Accessing confidential data - 2 step authentication support > > Hi Nikil, > > Good to know someone else is using Apache Isis in Australia, if you need > another resource I am in Hobart. > > I started to look a two factor authentication via Apache Shiro, maybe an > external authentication server/service/product already has the capacity to > have separate kinds of authentication for the same user and its just a case > of in Apache Isis forcing a reauthentication (using the two level protocol > with the external service if the user attempts to access a medical record ? > > I think its difficult to store and update very complex medical records in > a relational database model. Hospital systems make use of specialised > databases i read, for performance reasons. So you are looking at a second > system to do that well, but that is not to say that Apache Isis cannot have > functionality added. > > Just my two bits. > > Steve Cameron > > On Wed, Nov 29, 2017 at 10:13 PM, Nikhil Dhamapurkar < nikhil.dhamapurkar@ > healthengine.com.au> wrote: > > > Hi Everyone, > > > > We have a use case where an entity Patient has data with 2 parts. 1) > > non confidential details ( like name, last name) & 2) some > > confidential data associated with it (like medical records). > > > > We want to enable a 2 factor Authentication when retrieving the > > confidential data when calling ISIS from the REST based swagger API > > has someone came across a similar use case ? > > > > I would like to know if it will be advisable to have apache ISIS own > > the Model and have both the details confidential and non confidential > > as part of the entity and do validation via ISIS or will be better To > > keep the confidential data in an entity/data store outside of apache > > ISIS ? > > > > Application requests → level 1 Authentication → (Gets non > > confidential > > data) → based on the data and encrypted key → sends request to another > > source to get confidential data from it. > > > > OR > > > > Application Requests → with level 1 and Level 2 access Identifiers→ > > apache ISIS Identifies it has both tokens → returns the confidential > > data as well in the response. > > > > Regards > > Nikhil > > > > > > Kühne + Nagel (AG & Co.) KG > Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE > 812773878. > Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Dr. Hansjörg Rodi (Vors. ), > Martin Brinkmann, Holger Ketz, Jan-Hendrik Köstergarten, Nicholas Minde, > Michael Nebel, Lars Wedel, Matthias Weiner. > Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform: > Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745, > Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt. > Geschäftsleitung Region Zentral- und Osteuropa: Dr. Hansjörg Rodi (Vors.), > Thierry Held, Uwe Hött, Richard Huhn, Holger Ketz, Jan-Hendrik > Köstergarten, Jan Kunze, Michael Nebel, Guillaume Sauzedde, Mustafa Sener. > > Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen > Spediteurbedingungen 2017 (ADSp 2017). Hinweis: Die ADSp 2017 weichen in > Ziffer 23 hinsichtlich des Haftungshöchstbetrages für Güterschäden (§ 431 > HGB) vom Gesetz ab, indem sie die Haftung bei multimodalen Transporten > unter Einschluss einer Seebeförderung und bei unbekanntem Schadenort auf 2 > SZR/kg und im Übrigen die Regelhaftung von 8,33 SZR/kg zusätzlich auf 1,25 > Millionen Euro je Schadenfall sowie 2,5 Millionen Euro je Schadenereignis, > mindestens aber 2 SZR/kg, beschränken. Die ADSp sind auf unserer Webseite > als Download erhältlich. Auf Anfrage senden wir Ihnen diese auch gerne zu. > >
