|
From: Carl S. <car...@pn...> - 2022-12-13 21:05:50
|
You are correct. ... who are we connecting to? Right now... pretty much nobody. But someone has to be first. If we are first, then it (might) mean that people are connecting to us. You are also correct about the Provincial eForms project. The limitation is not technical ... but the power of that idea is that *if* people use it and see and experience how simple and powerful it is compared to what we do now (fax) then they would have a taste of what could and should be possible and then wonder why everything doesn’t work like this. Right now there are no market pressures on EMR vendors or other health software product companies to adapt or evolve. … as the EMR vendors (open source projects excluded) are beholden to their shareholders, they actually have a vested interest in NOT implementing FHIR and keeping customers (and by extension, patient data) locked into their ecosystems…. The problem is that for physicians and patients, we need information in order to care for patients and help them make decisions and coordinate ongoing follow up. … so by extension, we need things like FHIR. Their are people in government and health system leadership who kind of get it… but are constrained by the system they are working in. Getting anything done in a government or health region is slow moving and at high risk of failure. To implement FHIR in OSCAR would take a tremendous amount of time, the multiple standards issue is a headache, and their are numerous other barriers to contend with… … but it just might be worth the effort. Because if a colleague sees me sending or receiving a consult letter via FHIR message, or sending off an STI form via the provincial eforms project… then they see what could and should standard. Maybe it leads them to switch to OSCAR… or maybe they ask their EMR vendor or health region or colleagues or government why this isn’t already implemented elsewhere. And then maybe, just maybe, momentum builds and the idea catches fire (see what I did there) and perhaps someday we won’t have to practice medicine in an information vacuum. I guess it is a Field of Dreams situation - if you build they will come. You just need to find people with enough technical literacy / experience to implement it… and those people have to have to have a fair amount of idiocy to spend all a significant amount of free time on what may turn out to be a fools errand. I am brand new to OSCAR - watched the project since med school circa 2014, just built it for the first time a couple of weeks ago. And I am not a Java developer. So I am one 1-2 years away from having enough familiarity with the nuts and bolts to work on it… but I am the exact kind of idiot who would dedicate what little free time they have to something like this. So if there are others out there who think it’s an idea worth pursuing, we should coordinate and pursue it. Carl On Tue, Dec 13, 2022 at 11:07 AM Peter H-C <phu...@gm...> wrote: > Possible (of course) > We have the tools to generate and presumably consume the FHIR XML > On the OSCAR side it would involve mapping all the schema into FHIR > resources > many aspects (Patient, Immunization, Submitting Provider, Organisation) > have already been mapped > > https://bitbucket.org/oscaremr/oscar/src/stable/src/main/java/org/oscarehr/integration/fhir/model/ > but considering how much more is needed it would *not* be trivial > > and then to what standard (FHIR covers a wide range of them)? > One could invent one (most organisations have no issues with that from my > understanding) > Or one could use > U.S. Core Data for Interoperability > <https://www.healthit.gov/isa/us-core-data-interoperability-uscdi> – or > USCDI - data classes and elements. > One would have to land on a given version of course... > the current one being USCDI v3 > Then potentially make adjustments for version codes and other Canadian isms > > Which brings up the use case. Who are we connecting to? > If its just a one off to move charts, no matter how tedious and finicky it > is to do by schema and table, we know it works, > this could be as buggy as the current OMD standard implementation > Because ultimately error handling (when the XML data does not fit the > table definition or vice versa) will be the make or break > > > > > > > ================ > Peter Hutten-Czapski > Haileybury Ontario > > "The attitude that ‘if rural people want these services they’ll have to > come to the city to get them’ is simply not acceptable…” (Newbery, 1999) > > Before printing, think about the environment. Avant d' imprimer, pensez à > l'environnement. > > > On Tue, 13 Dec 2022 at 13:26, Earl Wertheimer <ea...@gm...> wrote: > >> I changed the subject to start another thread... >> I have a lot of experience with X12 documents, which are the same as HL7 >> and FHIR... >> >> Currently the Admin, Data Management, Demographic Export uses Demographic >> Patient Sets and generates EMR DM 5.0 or E2E formats. >> >> I have also thought about a generic Oscar export/import format that would >> facilitate transfers between Oscar sites/physicians/forks... >> The current Oscar import (from another Oscar site) is a pain... >> The old CMS format never worked correctly and the bulk database import is >> fast but messy. >> (I have not examined the newer EMR DMS 5.0 process) >> >> What about adding an FHIR export format? >> ... and a similar FHIR Import procedure? >> >> It would be easy for me to write the export as an SQL stored procedure... >> and I have already written multiple XML imports into Oscar. >> >> Someone would have to tweak the front-end to add that choice to the >> Export Template.. and later to the Demographic Import, since I don't have >> that knowledge (currently). >> >> .. It would also put Oscar in a better position wrt future FHIR >> integration. >> >> Useful or a waste of time? >> >> >> >> >> On Tue, Dec 13, 2022 at 7:19 AM Peter H-C <phu...@gm...> >> wrote: >> >>> OSCAR if I remember correctly has FHIR support since around 2018 >>> and uses FHIR to connect for BORN and DHIR to submit Ontario obstetrics >>> and Immunization data >>> You have no argument that FHIR are the new EMR data transfer standards >>> >>> The limitation is not technical. >>> The limitation always is getting enough of a use case to abandon legacy >>> There are people who like changing their form on paper (easy right, you >>> know places that do it every 6 months) >>> but to do it with system X they have to get authentication, learn the >>> new system (that they use only every 6 months, and damm it the password >>> stale dates quarterly) AND upload their legacy forms >>> and to convince their IT to build a back end that can convert FHIR XML >>> to something that they can use >>> >>> Think about PrescribeIt which has a less steep hill to climb >>> While OSCAR doesn't have PrescribeIt support (the forks might), that's >>> also built on a version of FHIR >>> There are a limited number of pharmacy softwares in Canada and they have >>> PrescribeIt support built in for competitive reasons (go private enterprise) >>> and yet in our neck of the woods there are very few pharmacies that have >>> it turned on (Walmart and one large independent AFAIK) >>> and on the MD end there is limited business case to go there as you need >>> to support Paper, Fax and PrescribeIt and who wants multiple workflows? >>> ================ >>> Peter Hutten-Czapski >>> Haileybury Ontario >>> >>> "The attitude that ‘if rural people want these services they’ll have to >>> come to the city to get them’ is simply not acceptable…” (Newbery, 1999) >>> >>> Before printing, think about the environment. Avant d' imprimer, pensez >>> à l'environnement. >>> >>> >>> On Mon, 12 Dec 2022 at 21:39, Carl Severson <car...@pn...> >>> wrote: >>> >>>> The provincial eForms solutions utilizes HL7 FHIR messages to send / >>>> receive forms. It works via RESTful API calls, and therefore can utilize >>>> whatever form of security and encryption you desire to protect your server >>>> and patient data. >>>> >>>> FHIR has become a standard that has been rapidly and widely adopted >>>> across the world. Some countries, have legislated that it be baked in to >>>> every digitial healthcare product in use. The US legislated it as a >>>> standard 5 years ago - adherence and compliance to that standard came into >>>> effect there a few weeks ago. >>>> >>>> People have tried to find a standard for healthcare data for years >>>> (except the province of British Columbia... they have been too disorganized >>>> to even try), but all of them have failed. >>>> >>>> FHIR has actually suceeded. >>>> >>>> I would recommend reading the NEJM that proposed this as a solution in >>>> 2009, and this NEJM from a few days ago for more a brief non-technical >>>> overview (both attached) >>>> >>>> As an anology, consider electricity: >>>> >>>> In the 1880s Edison and Tesla were battling it out to establish Direct >>>> Current (DC) or Alternating Current (AC) as a standard. Eventually, we >>>> settled on AC running at 60 Hertz and 120volts with 3-prong plug (220 volts >>>> in Europe, 50Hz in Germany for some reason, and a few different plug type >>>> variations). As a result, I can plug in any appliance in my house and it >>>> works. If my fridge stops working, then I can go over to Dennis Warren's >>>> house, grab his fridge, bring it over to my house and plug it in and keep >>>> all my groceries (and his groceries) fresh and my family fed (thanks >>>> Dennis!!!!). >>>> >>>> We take it for granted, but when you sit down and think about it, >>>> having a common electrical standard enables us to do incredible things. >>>> >>>> Yes, you need a 220volt outlet for your stove or dryer... or if you go >>>> to Europe you might need a different plug or a transformer (you can get a >>>> little travel adapter for $15 dollars), but for the overwhelming majority >>>> of use cases you can plug anything in anywhere safely, without thinking >>>> about it. >>>> >>>> If FHIR is a 120 Volt 60 Hz 3 prong plug in this analogy then the rest >>>> of the world is almost finished establishing this as a standard and they >>>> are easily and safely plugging in their appliances. Don't get me wrong, >>>> they still have a loooong ways to go, but Canada is a minimum of 10 years >>>> behind, and we are still sitting around hard wiring all of our appliances >>>> into the grid directly while sparks are flying and people's houses burn >>>> down from electrical fires with ashtonishing regularity. >>>> >>>> The only products that I know of in Canada that are FHIR capable are >>>> Cortico and Cognisant MD's Ocean (Ocean only having a small amount of FHIR >>>> capability as far as I can see). >>>> >>>> Every single one of us should be emailing, calling, demading, >>>> applauding, and begging the PHSA to keep their eForm project alive and >>>> moving forward. And all of us should start working on FHIR implementation >>>> in OSCAR and elsewhere... because based on their track record thus far... >>>> if we leave it up to the Federal and Provincial governments, Telus, QHR, >>>> WELL, or others to do it for us, our patients and ourselves are more likely >>>> to die of electrocution while waiting, than they are at making any progress >>>> happen. >>>> >>>> I would recommend going back and watching the PHSA demo of this again: >>>> https://www.youtube.com/watch?v=302ljX4qrbI&ab_channel=OSCARBC-ConnectingCare.CreatingCommunity. >>>> >>>> Their website is here: https://eformsinfo.healthcarebc.ca/about >>>> >>>> Email, call, write, send carrier pigeons, and make sure they know we >>>> want and need this - or better yet, that we need them to help expedite >>>> adoption and development of the technology underlying this. >>>> >>>> </rantover> >>>> >>>> On Mon, Dec 12, 2022 at 3:50 PM John Yap <joh...@gm...> wrote: >>>> >>>>> OMG - I actually have done this already - but for a much simpler >>>>> website called PaRx - for nature prescription to Provincial Parks in BC. >>>>> Unfortunately the PHarmacare site is very convoluted with multiple drop >>>>> down boxes and separate menus, etc, etc. >>>>> >>>>> Heck - you wouldn't expect Gov't to make something relatively simple >>>>> even more simple would you?! >>>>> >>>>> JohnY >>>>> >>>>> On Mon, Dec 12, 2022 at 3:29 PM Peter H-C <phu...@gm...> >>>>> wrote: >>>>> >>>>>> IF pharmacare exposes their form to you, it is trivial to fill it out >>>>>> of OSCAR, even if you don't have access to the source code. >>>>>> >>>>>> EForms (OSCAR) to the rescue! >>>>>> >>>>>> Determine the "names" of the fields in Pharmacare (use FF to inspect >>>>>> the page for the names) create an eform that contains the values >>>>>> And have the eform link via JavaScript to a url that assembles them >>>>>> >>>>>> Something like this >>>>>> >>>>>> Http:/Pharmacare/form?name=value >>>>>> >>>>>> On Mon, Dec 12, 2022, 17:57 John Yap, <joh...@gm...> wrote: >>>>>> >>>>>>> So, the confusingly named “Provincial eFORM Solution” was not an >>>>>>> attempt to get all doctors onto Oscar to use our great eFORMS…..sadly! >>>>>>> >>>>>>> It was meant to be a seamless way to integrate bidirectional >>>>>>> communications into all EMRs - such that requests could be done directly >>>>>>> from any EMR, and all relevant information would be included, and if not, >>>>>>> could be acquired, with the additional feature of tracking - obviously this >>>>>>> would apply to imaging req, drug requests (special authority), lab req, >>>>>>> consultation etc. >>>>>>> >>>>>>> It would (hopefully) me out of my misery of constantly updating our >>>>>>> Oscar eFORMS to match the sometimes random output from the various agencies >>>>>>> that have more time than - fill in the blank - to change requisitions >>>>>>> because they can! >>>>>>> >>>>>>> BUT what about security you ask? I think that was asked a lot >>>>>>> actually. Would you allow PHSA to push and pull from your EMR? We do that >>>>>>> now, but only with Teleplan, and only when we submit and receive >>>>>>> remittances/claims. How about allowing that for your entire EMR? Anyone??? >>>>>>> >>>>>>> Now consider the newest iteration of that - vis a vis Pharmacare >>>>>>> Approval - through their portal. It’s far from integrated into Oscar. >>>>>>> Likely never will be, but where there’s a will there’s a way. I hope to >>>>>>> generate a possible solution before New Years! >>>>>>> >>>>>>> BUT you have to manually populate the “form” with your patient >>>>>>> demographics and even your own, even though you’ve securely logged in as >>>>>>> yourself! So why go through that effort? Because the approval is >>>>>>> literally instant - whereas the faxed eFORM route takes weeks if not >>>>>>> months! And will probably be removed ask an option in the very new >>>>>>> future. Imagine the cost savings of firing all their data entry clerks, >>>>>>> because they have us MD’s doing that now for………free? >>>>>>> >>>>>>> These solutions are a bit one-sided, eh? >>>>>>> >>>>>>> JohnY >>>>>>> >>>>>>> On Dec 12, 2022, at 1:00 PM, Colcamex Resources Inc. < >>>>>>> dw...@co...> wrote: >>>>>>> >>>>>>> >>>>>>> I understood the Provincial Eform Solution enhanced *secure* bi >>>>>>> directional communication with 3rd parties (patients, EMRs, labs etc...). >>>>>>> Of course it would never replace OSCAR’s eform solution - but - it was a >>>>>>> very welcomed enhancement to BC’s fragmented HIT structure. >>>>>>> >>>>>>> Dennis Warren >>>>>>> >>>>>>> >>>>>>> On Dec 12, 2022, at 12:28 PM, John Robertson < >>>>>>> joh...@sh...> wrote: >>>>>>> >>>>>>> BC eForm project was basically about fillable PDFs, not eForms in >>>>>>> the OSCAR sense. JohnR. >>>>>>> >>>>>>> On Mon., Dec. 12, 2022, 11:38 Colcamex Resources Inc., < >>>>>>> dw...@co...> wrote: >>>>>>> >>>>>>>> >>>>>>>> I wonder what happened with the BC Provincial Eform project? >>>>>>>> >>>>>>>> Dennis Warren >>>>>>>> >>>>>>>> On Dec 11, 2022, at 10:53 AM, Adrian Starzynski <ad...@ad...> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Yes, you can link eForms to third party services that allow it to >>>>>>>> be sent since eForms are just HTML pages that can handle javascript. These >>>>>>>> integrations “take” the eForm and send a copy through the online >>>>>>>> integration to a URL/API and perform the operation (like send phq9 >>>>>>>> questionnaire) and then patient fills it and it comes back via OSCAR API as >>>>>>>> a document or they send back as attachment. But that itself requires API >>>>>>>> integration beyond the sole eForm. So the simple answer is that eforms >>>>>>>> themselves can’t do these functions, there needs to be a back end to >>>>>>>> support them. >>>>>>>> >>>>>>>> -- >>>>>>>> Adrian Starzynski >>>>>>>> www.aditech.ca >>>>>>>> >>>>>>>> >>>>>>>> *From: *John Yap <joh...@gm...> >>>>>>>> *Date: *Sunday, December 11, 2022 at 1:45 PM >>>>>>>> *To: *A list for advanced OSCAR user discussions < >>>>>>>> osc...@li...> >>>>>>>> *Cc: *The OSCAR UserGroup list < >>>>>>>> osc...@li...> >>>>>>>> *Subject: *Re: [Oscarmcmaster-bc-users] [OSCAR-advanced-users] >>>>>>>> eForms can do database functions like Forms can >>>>>>>> Where there's a will, there's a way. And there are users out there >>>>>>>> more clever than me who've already figured this out. Here are a couple of >>>>>>>> scenarios already in play - in BC, Pathways has a feature that allows for >>>>>>>> FORMS - not necessarily eFORMS, but general questionnaire type forms such >>>>>>>> as PHQ9, ADHD forms, even MVA intake forms - to be completed and sent back >>>>>>>> to the clinic via secure eMAIL prior to visits. >>>>>>>> >>>>>>>> Another physician user/developer has created a system by which an >>>>>>>> actual Oscar eFORM can be securely sent to the patient, completed, and >>>>>>>> securely returned to the EMR, and the patient's chart. VERY cool. I >>>>>>>> haven't had a chance to try this. >>>>>>>> >>>>>>>> A developer has created a series of mental health-related eFORMS >>>>>>>> that can be similarly sent to the patient and returned to the EMR >>>>>>>> securely. It was in development when I last had contact with the developer >>>>>>>> and I'm not sure where it landed. It was primarily developed for his >>>>>>>> spouse who needed this functionality. Of course, this "technology" could >>>>>>>> be applied to many other treatment areas. >>>>>>>> >>>>>>>> And of course, the offerings by Ocean and other subscription type >>>>>>>> services. >>>>>>>> >>>>>>>> So it's already out there! >>>>>>>> >>>>>>>> JohnY >>>>>>>> >>>>>>>> On Sun, Dec 11, 2022 at 10:13 AM Adrian Starzynski <ad...@ad...> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Oscar eforms are accessible strictly from within Oscar only, >>>>>>>> meaning they cannot be publicly accessed so you couldn’t have a patient >>>>>>>> enter their response to an eform… for that you’d have to use a third party >>>>>>>> system. Ocean’s patient forms feature which they call “eforms” is easy to >>>>>>>> get confused with Oscar EForms… just keep in mind that Ocean eForms have >>>>>>>> nothing to do with Oscar’s eForms; they are separate XML forms that you can >>>>>>>> create within the ocean platform to collect text-based data from patients. >>>>>>>> The ocean eforms’ responses get stored as text encounter notes/PDF document >>>>>>>> in OSCAR and they don’t update the database with any information. I’ve only >>>>>>>> seen ocean eForms used for patient symptom collection before a visit, and >>>>>>>> for consent forms. >>>>>>>> With ocean to share anything you still have to download it as a PDF >>>>>>>> and re upload to Oscar which is a lot of repetitive clicks. Cortico plugin >>>>>>>> allows you to select eForms/documents/labs to attach to the secure message >>>>>>>> directly from Oscar without needing to download and re-upload anything. I >>>>>>>> may be a bit biased since I used Ocean and now solely Cortico in my clinic >>>>>>>> for these reasons. >>>>>>>> >>>>>>>> -- >>>>>>>> Adrian Starzynski >>>>>>>> www.aditech.ca >>>>>>>> >>>>>>>> >>>>>>>> *From: *Vera Summers <vsu...@ha...> >>>>>>>> *Date: *Sunday, December 11, 2022 at 12:37 PM >>>>>>>> *To: *The OSCAR UserGroup list < >>>>>>>> osc...@li...>, A list for advanced >>>>>>>> OSCAR user discussions < >>>>>>>> osc...@li...> >>>>>>>> *Subject: *Re: [Oscarmcmaster-bc-users] eForms can do database >>>>>>>> functions like Forms can >>>>>>>> Is there any way to publish the E-Form so that the patient can fill >>>>>>>> in some fields? >>>>>>>> >>>>>>>> Thank you, >>>>>>>> >>>>>>>> >>>>>>>> <image001.gif> <http://www.harrisonhealthcare.ca/> >>>>>>>> *Vera Summers* >>>>>>>> Information Management Officer >>>>>>>> >>>>>>>> *Mobile*: (778) 840-3844 >>>>>>>> *www.harrisonhealthcare.ca* <http://www.harrisonhealthcare.ca/> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *From:* Adrian Starzynski <ad...@ad...> >>>>>>>> *Sent:* Sunday, December 11, 2022 8:14 AM >>>>>>>> *To:* A list for advanced OSCAR user discussions < >>>>>>>> osc...@li...>; The OSCAR >>>>>>>> UserGroup list <osc...@li...> >>>>>>>> *Subject:* [Oscarmcmaster-bc-users] eForms can do database >>>>>>>> functions like Forms can >>>>>>>> >>>>>>>> Several times I have heard folks saying that eForms aren’t as >>>>>>>> advanced as Forms and some Forms won’t ever be converted into eForms… all >>>>>>>> because eForms can’t modify existing values in the Oscar database like >>>>>>>> Forms could… >>>>>>>> I’ve dug up some older memos, and extensively tested and >>>>>>>> consolidated instructions for using Enhanced Database Tags in Oscar eForms, >>>>>>>> only published here: eForm Magic Part C – Enhanced Database >>>>>>>> Operations - World OSCAR >>>>>>>> <https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fworldoscar.org%2Fknowledge-base%2Feform-magic-part-c-enhanced-database-pulling%2F&data=05%7C01%7Cvsummers%40harrisonhealthcare.ca%7C5fe2905bf8c0429e942f08dadb92cfd2%7Cffbdc2aef63d4aac996728a0b50977fa%7C1%7C0%7C638063720851474873%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=4ULKveizBeUycDiKzNW26%2Fn2EsBH00t68xDhTvrcAW8%3D&reserved=0> >>>>>>>> >>>>>>>> Chiefly among these enhanced DB tags is the ability to update Oscar >>>>>>>> database values, just like forms could. >>>>>>>> This is how some advanced forms (like OPR 2017) have been converted >>>>>>>> to eForms and they serve the same (and in some cases, better) >>>>>>>> functionality. Plus, eForms come with the benefit that they are totally >>>>>>>> customizable unlike forms. Want another checkbox on page 3? Piece of cake, >>>>>>>> you can just add it yourself whenever. >>>>>>>> >>>>>>>> For those wondering if you can take advantage of these enhanced DB >>>>>>>> tags that modify values in the DB if you are on a hosted OSP like WELL ? >>>>>>>> the answer is yes. You can ask them to change your apconfig.xml file to add >>>>>>>> custom DB tags or <ap-insql> to permit modification of values in the DB >>>>>>>> etc... i.e. WELL has helped my clinic a lot with customizing the >>>>>>>> apconfig.xml and we have a lot of custom tags that I use in eForms. >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Adrian Starzynski >>>>>>>> www.aditech.ca >>>>>>>> <https://can01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.aditech.ca%2F&data=05%7C01%7Cvsummers%40harrisonhealthcare.ca%7C5fe2905bf8c0429e942f08dadb92cfd2%7Cffbdc2aef63d4aac996728a0b50977fa%7C1%7C0%7C638063720851474873%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=YxLoMqtrWsaRVEaBULLXdXjx%2F5EcfMxg8daXiTHAxAk%3D&reserved=0> >>>>>>>> >>>>>>>> CYBER RISK CAUTION:This email originated from outside of the >>>>>>>> organization. Do not click links or open attachments unless you recognize >>>>>>>> the sender, expected to receive this content and trust that it’s safe. If >>>>>>>> you determine that the email isn’t from a trusted source, you should delete >>>>>>>> it. >>>>>>>> _______________________________________________ >>>>>>>> OSCARmcmaster-advanced-users mailing list >>>>>>>> OSC...@li... >>>>>>>> >>>>>>>> https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-advanced-users >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OSCARmcmaster-advanced-users mailing list >>>>>>>> OSC...@li... >>>>>>>> >>>>>>>> https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-advanced-users >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OSCARmcmaster-advanced-users mailing list >>>>>>>> OSC...@li... >>>>>>>> >>>>>>>> https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-advanced-users >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Oscarmcmaster-bc-users mailing list >>>>>>> Osc...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-bc-users >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OSCARmcmaster-advanced-users mailing list >>>>>>> OSC...@li... >>>>>>> >>>>>>> https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-advanced-users >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OSCARmcmaster-advanced-users mailing list >>>>>>> OSC...@li... >>>>>>> >>>>>>> https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-advanced-users >>>>>>> >>>>>> _______________________________________________ >>>>>> OSCARmcmaster-advanced-users mailing list >>>>>> OSC...@li... >>>>>> >>>>>> https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-advanced-users >>>>>> >>>>> _______________________________________________ >>>>> OSCARmcmaster-advanced-users mailing list >>>>> OSC...@li... >>>>> >>>>> https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-advanced-users >>>>> >>>> _______________________________________________ >>> OSCARmcmaster-advanced-users mailing list >>> OSC...@li... >>> https://lists.sourceforge.net/lists/listinfo/oscarmcmaster-advanced-users >>> >> |
