|
|
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
zeon11alexeyvgпропущено... Как я понял, им нужно понять, как хранить и обрабатывать данные для "всего". И в принципе такое желание правильно, тем более что граница платные/бесплатные достаточно размыта, бесплатные - это платные, которые оплачиваются другим способом, да и вообще вся эта отрасль сечас непрерывно меняется. А тут рецепт один - мы должны чётко зафиксировать в БД самый мельчайший факт, который с точки зрения наблюдателя из предметной области представляет интерес. Иными словами, если для врача важно, сколько раз пациент пукнул за приём, то мы должны в БД зафиксировать каждый пук, с указанием времени, длительности и громкости события. Тогда имея такие данные, мы всегда сможем их обобщить.Ну да, я про это и говорю ТС. Ну конечно, нужно выбирать, что записывать, находить компромисс между "слишком трудоёмко для пользователей записать всё, что произошло" и "не записаны факты, которые необходимы для дальнейшего анализа" Но главное - неправильно на этом этапе обрабатывать факты и писать вместо них результат анализа. Просто с таким подходом сложнее разрабатывать и модифицировать систему, при любом изменении требований нужно будет "переписывать всё" с последующей мучительной отладкой и внедрением. Пропадают инвестиции. И чем система в целом сложнее и универсальнее, тем важнее это правило. Допустим, если лаборатория наймёт программиста для написания собственной не связанной ни с чем системы учёта, то можно сущности тупо срисовать с инструкций по отчётности, всё будет просто и надёжно. Но при усложнении, чем больше учитывается, тем больше нужно идти в сторону многофазных обработок от фиксации фактов до формирования данных для конечного учёта. Это как сравнить простенький интернет-магазин и полноценную учётную систему торговой фирмы. В первом случае можно делать записи ближе к конечному бизнес-процессу, во втором система раскладывается на учёт фактов (допустим, движение по складу) и какие то фазы постобработки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 10:35 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekbа где-нибудь написано подробней про идею сущностей и событий? Не думаю, просто best practics ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 11:36 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
zeon11, спасибо за предложение о сотрудничестве! Нам очень нужны партнеры, но пока не знаю чем именно мы сможем друг другу помочь. Мы осознаем, что систему с таким охватом автоматизируемой деятельности как у вас нам разрабатывать ещё лет 5. Поэтому основной акцент делаем на вещах, которых нет или которые очень слабо развиты в других МИС. Это более универсальная схема данных, которая позволит упростить поддержку и развитие системы. Это анализ процессов, классификаторы, поддержка принятия решений. У нас относительно крупное мед.учреждение, многие врачи занимаются научной работой, у них полно идей для воплощения в ИТ. Словом, мы не занимаемся чисто автоматизацией деятельности, проект в значительной степени исследовательский. По поводу платных услуг. А в этом списке у вас есть операции (стационарные) или манипуляции стоматолога? Операции, которые заводятся в стационаре хранятся в той же таблице, что и платные услуги врача поликлиники? А манипуляции стоматолога? А в регистратуре у вас ведется учет посещений? Талоны амбулаторного пациента заносятся в базу? Если да, то вы ведете учет на двух уровнях детализации (посещения и услуги). А что если статистикам понадобится посчитать количество платных посещений (а не услуг, их будет больше, чем посещений)? А если врачи в "бесплатной" поликлинике захотят учитывать не только посещения, но и услуги, которые они оказывали в рамках этих посещений? Как платные услуги завязаны с ЭИБ? Услуги отмечаются отдельно, медицинские записи - отдельно? Или они связаны между собой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 14:15 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekbпроект в значительной степени исследовательский. Посему бесплатный совет: купите готовый движок и на нем делайте свой проект. Будете тупо кодить - ничего не выйдет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 14:49 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
alexeyvgТо есть для каждой преджметной области придумывается такой набор первички, который позволяет сохранить все значимые факты.Проблема в том, что у нас 2 предметных области: "бесплатная" и хозрасчетная поликлиники. В первой минимальным фактом является посещение. А во второй - услуга. Нужно эти области как-то объединить: либо заставить регистраторов бесплатной поликлиники заносить услуги вместо посещений (а все посещения будут генириться на основе услуг), либо регистраторов платной поликлиники заставить дополнительно к услугам отмечать ещё и посещения. В принципе, первый вариант вполне реализуемый, но придется делать 2 варианта формы ввода услуги (одна приближенная талону амбулаторного пациента, другая - к договору). Второй вариант - это как сделано сейчас, одна форма, но удобная только для бесплатной регистратуры и то, не очень. alexeyvgВ первом случае можно делать записи ближе к конечному бизнес-процессу, во втором система раскладывается на учёт фактов (допустим, движение по складу) и какие то фазы постобработки.Ага, по-моему в этом и проблема. Пользовательский интерфейс должен быть максимально приближен к бизнес-процессу. В нашем случае идет разрыв между интерфейсом и схемой данных, что не очень хорошо. Но, видимо, это необходимая жертва. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 14:55 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
_мод, спасибо за совет! В принципе, с этим и связан 4-ый этап переписывания системы. Изначально было несколько ужасных систем Delphi, Access, FoxPro. Потом один товарищ решил переписать всё на C#, MS SQL - технологии другие, код такой же. Потом я попытался сделать хоть какой-то адекватный движок. Он, конечно, позволил избавиться от 80% кода, но сейчас требования изменились, дорабатывать движок нет никаких ресурсов. С переходом на готовый фреймвок, мы выкинем ещё 80% кода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 15:02 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekbПроблема в том, что у нас 2 предметных области: "бесплатная" и хозрасчетная поликлиники. В первой минимальным фактом является посещение. А во второй - услуга. Нужно эти области как-то объединить: либо заставить регистраторов бесплатной поликлиники заносить услуги вместо посещений (а все посещения будут генириться на основе услуг), либо регистраторов платной поликлиники заставить дополнительно к услугам отмечать ещё и посещения.Печально, вы даже поверхностно не прочитали, что я написал :-( Ares_ekbВ нашем случае идет разрыв между интерфейсом и схемой данных, что не очень хорошо. Но, видимо, это необходимая жертва.Какой у вас критерий "хорошо"? Это красивое, испольуемое ещё за сотни лет до появления ЭВМ, и единственное из работающих (при хоть какой-то сложности процессов) архитектурное решение, а не "жертва". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 16:20 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekbВ принципе, с этим и связан 4-ый этап переписывания системы. Изначально было несколько ужасных систем Delphi, Access, FoxPro. Потом один товарищ решил переписать всё на C#, MS SQL - технологии другиеО да, вот в чём дело - язык программирования был выбран не такой :-) Можно ещё ввести журнал опозданий, после этого уж точно будет сделан проект. Архитектора бы вам надо хорошего, или руководителя проекта :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 16:23 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekbПроблема в том, что у нас 2 предметных области: "бесплатная" и хозрасчетная поликлиники. В первой минимальным фактом является посещение. А во второй - услуга. Нужно эти области как-то объединить: либо заставить регистраторов бесплатной поликлиники заносить услуги вместо посещений (а все посещения будут генириться на основе услуг), либо регистраторов платной поликлиники заставить дополнительно к услугам отмечать ещё и посещения. Вменяемый пользователь пошлёт Вас {очень далеко} при попытке заставить его делать что-то ему нафиг не нужное, и будет абсолютно прав. Таким путём и появляются "формально внедрённые" монстры, в которых систему вроде как купили, а конечные пользователи её сливают. А "нужно" сделать то, что реально нужно клиентам. Если в поликлинике А не нужны услуги - вот нет у них в бизнес-процессе такого понятия - значит, не нужно показывать им услуги и что-то от них требовать. Если вашему движку эти услуги нужны - прячьте внутрь и генерите автоматом. Со второй поликлиникой соответственно. Ares_ekbПользовательский интерфейс должен быть максимально приближен к бизнес-процессу. Не всегда. Ares_ekbВ нашем случае идет разрыв между интерфейсом и схемой данных, что не очень хорошо. Но, видимо, это необходимая жертва. Схема данных и бизнес-процесс - вовсе разные вещи. Разрыв между интерфейсом и схемой данных - это совершенно нормально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 16:28 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
alexeyvgПечально, вы даже поверхностно не прочитали, что я написал :-( Прочитал, но, видимо, не понял, намекните, пожалуйста... Ares_ekbКакой у вас критерий "хорошо"? Это красивое, испольуемое ещё за сотни лет до появления ЭВМ, и единственное из работающих (при хоть какой-то сложности процессов) архитектурное решение, а не "жертва".Хорошо - просто и дешево, когда интерфейс генерится автоматически под предметную область, описал её и всё. А тут приходится затрачивать дополнительные усилия. Ну, хотя, да, так, действительно, не бывает. Предметная область должна быть как минимум 2-х уровневой. Например, у нас есть факт "стационарное оказание помощи пациенту". Сам этот факт напрямую практически не редактируется, и, вообще, мало понятен пользователю. Но с этим фактом связан десяток документов. В каждом документе описано какие атрибуты каких сущностей регистратор должен заполнить, т.е. фактически это набор ссылок на атрибуты реальных фактов, такой своеобразный виртуальный факт. Интерфейс для документов генерится автоматически. По сути мы изобрели аналог OpenEHR или HL7 CDA, убогий, но зато простой и понятный. Ares_ekbО да, вот в чём дело - язык программирования был выбран не такой :-)Ну, во-первых то, что там было сделано на Access и FoxPro вообще не поддается никакой критике, это просто ужас, сами технологии конечно не виноваты, но и они не айс. Чел, который переписывал всё на C# по крайней мере понимал, что вместо 20 баз нужна одна, и, что в БД должны быть хотя бы ключи (и первичные, и внешние) и хоть какая-то валидация данных, что посещение врача и посещение психолога - это одна сущность, а пациент и амбулаторная карта - разные, что база стационара должна использоваться не только для распечатки документов, но и облегчать жизнь статистикам - это можно перечислять бесконечно. Но он был слишком самоуверен, считая, что напишет всё сам с нуля без использования готового движка. Ещё он заблуждался в том, что такая система вообще кому-то нужна. В общем, дело не в ЯП ) Ares_ekbАрхитектора бы вам надо хорошего, или руководителя проекта :-)Всё несколько хуже. Туманна необходимость этого проекта в принципе. МИС полно. Зачем делать ещё одну? Мы ищем ответ, и вместе с ним, я надеюсь, найдём и деньги, и архитектора, и руководителя, и программистов. Кстати к вопросу о сотрудничестве, мы со своей стороны готовы принять деньги и помощь в разработке )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 18:17 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
softwarerВменяемый пользователь пошлёт Вас {очень далеко} при попытке заставить его делать что-то ему нафиг не нужное, и будет абсолютно прав.Да, но всё-равно у меня в подсознании сидит мысль, что пользователи работают неправильно А почему интерфейс не всегда должен быть приближен к бизнес-процессу? Я вообще думаю, что все учетные системы должны быть заменены на системы управления процессами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 18:27 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekbДа, но всё-равно у меня в подсознании сидит мысль, что пользователи работают неправильно Понимаю. Но с одной стороны, пользователя очень сложно в этом убедить. С другой - чем больше вникаешь в его работу, тем чаще понимаешь, что зря сидит эта мысль. Ares_ekbА почему интерфейс не всегда должен быть приближен к бизнес-процессу? Я вообще думаю, что все учетные системы должны быть заменены на системы управления процессами. Софт должен удачно интегрироваться в бизнес-процесс. Для этого часто полезно, чтобы интерфейс был к нему приближен, но тем не менее. Скажем, возьмите эксель - про его интерфейс никто такое не скажет, но софтина очень полезная. Другой пример: время от времени у моей жены на работе случаются завалы, и руководство собирается и планирует, как распорядиться людьми-оборудованием-транспортом, чтобы всё успеть. Вопрос, нужно ли автоматизировать решение таких завалов? Ответ: да нет, они случаются нечасто, автоматизация не окупится. Следующий вопрос: нужно ли приблизить интерфейс к бизнес-процессу и описать в ИС процесс этого совещания со всеми его предложениями, дёрганьями итдитп? Ответ: да нет, тем более не нужно. Вполне хватит и устраивает просто решения по итогам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 18:49 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
alexeyvgzeon11А тут рецепт один - мы должны чётко зафиксировать в БД самый мельчайший факт, который с точки зрения наблюдателя из предметной области представляет интерес.Ну да, я про это и говорю ТС.Наблюдателей несколько, один видит услуги, другой - посещения. Причем, оба являются учетчиками. alexeyvgНо главное - неправильно на этом этапе обрабатывать факты и писать вместо них результат анализа.Обработка фактов происходит всегда. В действительности нет ни посещений, ни услуг, ни движения товара на складе. Есть только физические, мыслительные, ... процессы (хотя, и их наверное тоже нет), которые наблюдатель идентифицирует, например, как поступление товара на склад. В реальности произошло огромное количество событий, которые были проанализированы/обработаны и внесены в базу как приход товара. Затем начальник склада аналогично обрабатывает факты движения товара и получает какие-то новые факты. А что если у этого начальника есть в подчинении склад (где-нибудь в Китае), где ведется не учет движения товара, а какой-то другой учет? Например, у них первичка - остатки. Или, например, в первом складе учет ведется по номенклатуре товаров, а во втором - по группам. Словом, вернулись к началу темы, тут всего 2 варианта: либо переучивать один из складов, либо программно реализовать приведение одного вида первички в другой. Можно ли тут придумать какой-то 3-ий вид первички, на который будет раскладываться и первая, и вторая не понятно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 21:32 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekb, словесный понос все это есть 8 лимонов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2012, 21:49 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
ViPRos, сделаю скидку на специфику форума и всё-таки спрошу: что именно? почему 8? и зачем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2012, 04:45 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekb, словесный понос - попытка подвести тухлую философию по обычные задач мне нужен как раз 8 лимнов срочно избавить вас от этой работы :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2012, 13:43 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
ViPRos, Спасибо, я в ваших услугах не нуждаюсь ) Задача наверное обычная... приведите хотя бы одну МИС, в которой она решена. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2012, 14:38 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekbalexeyvgНу да, я про это и говорю ТС.Наблюдателей несколько, один видит услуги, другой - посещения. Причем, оба являются учетчиками.А вы предметной областью считайте медицину, а не потребителей статистики. Тогда никакой двусмысленности - будут только факты контакта больного с врачём и факты каких либо действий врача и пациента (пациент тоже делает какие то действия в этом процессе). Это близко к реальной жизни, и это позволит получить нужную всем статистику без потерь какой либо информации. Про интерфейсы - понятно, что нужно их делать подходящими для каждого конкретного случая. Но это будет проще (как и должно быть для интерфейсов) - сейчас из за выбранной вами архитектуры относитесь к интерфейсам как к чему то священному, они у вас трудоёмкие в изгоитовлении, завязаны на постоянно и сильно меняющуюся модель данных. А с новой схемой будет проще - инерфейсы будут, как и положено, шелухой, нанятые кодеры будут их быстренько лабать (на разных языках и платформах) под разные подразделения и меняющиеся требования пачками. Модель данных не бдет меняться, интерфейсы соответственно не нужно будет переделывать под эти изменения - только под изменения бизнес-требований к интерфейсам, за часик, за день. Ares_ekbВ реальности произошло огромное количество событий, которые были проанализированы/обработаны и внесены в базу как приход товара. Затем начальник склада аналогично обрабатывает факты движения товара и получает какие-то новые факты. А что если у этого начальника есть в подчинении склад (где-нибудь в Китае), где ведется не учет движения товара, а какой-то другой учет? Например, у них первичка - остатки.Издревле первичка для складов - это "приход товара" и "уход товара". Всё. Где бы как бы не велась отчётность и учёт - первичка не меняется. Это тысячи лет так, и сомневаюсь, что какой то склад где-нибудь в Китае делает по другому. Вот и ищите в вашей предметной области такую правильную первичку, которая была тысячи лет и не изменится ещё столько же (то есть для медицины: приём врача-действия врача, только не те, которые подразумевает статистика, а те, которые подразумевают участники действа - пациент и врач, причём врач, не работающий в какой либо системе зравохранения :-) ). Не внедряйте новую первичку, которой не было хотя бы сотню лет назад. А уже из этой "правильной" первичке легко получите любую информацию - для работ, которые на самом деле приёмы, для приёмов, которые работы и т.д. Ares_ekbИли, например, в первом складе учет ведется по номенклатуре товаров, а во втором - по группам.А вот это уже детали учёта. Конечно, при подборе хранимых атрибутов нужно учитывать и потребености статистики, и т.п. Но при правильной модели будет несложно добавить атрибут при необходимости. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2012, 17:31 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekbViPRos,Спасибо, я в ваших услугах не нуждаюсь )зря отказываешься, он мог бы решить, имхо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2012, 00:13 |
|
||
|
Документы или факты
|
|||
|---|---|---|---|
|
#18+
Ares_ekbzeon11, спасибо за предложение о сотрудничестве! Нам очень нужны партнеры, но пока не знаю чем именно мы сможем друг другу помочь. Мы осознаем, что систему с таким охватом автоматизируемой деятельности как у вас нам разрабатывать ещё лет 5. Поэтому основной акцент делаем на вещах, которых нет или которые очень слабо развиты в других МИС. Это более универсальная схема данных, которая позволит упростить поддержку и развитие системы. Это анализ процессов, классификаторы, поддержка принятия решений. У нас относительно крупное мед.учреждение, многие врачи занимаются научной работой, у них полно идей для воплощения в ИТ. Словом, мы не занимаемся чисто автоматизацией деятельности, проект в значительной степени исследовательский. По поводу платных услуг. А в этом списке у вас есть операции (стационарные) или манипуляции стоматолога? Операции, которые заводятся в стационаре хранятся в той же таблице, что и платные услуги врача поликлиники? А манипуляции стоматолога? А в регистратуре у вас ведется учет посещений? Талоны амбулаторного пациента заносятся в базу? Если да, то вы ведете учет на двух уровнях детализации (посещения и услуги). А что если статистикам понадобится посчитать количество платных посещений (а не услуг, их будет больше, чем посещений)? А если врачи в "бесплатной" поликлинике захотят учитывать не только посещения, но и услуги, которые они оказывали в рамках этих посещений? Как платные услуги завязаны с ЭИБ? Услуги отмечаются отдельно, медицинские записи - отдельно? Или они связаны между собой? В этом списке, скрин фрагмента которого я привёл находится всё: услуги поликлиники, стоматолога, стационара, платные палаты и т.д. Т.е. всё то, что учреждение может дать (продать) пациенту, а пациент согласен принять. Этот список как видно на скрине, называется обобщённо - "услуги". Поскольку в некоторых учреждениях, где работает программа таких услуг может быть достаточно много (например, в одной городской больнице 40 отделений, более 1800 "живых" услуг) структура списка достаточно сложна. Как видно, на скрине, она иерархическая, количество вложений не ограничено, но в реале, более чем на 5 колен экономисты не делали. Поскольку оформление услуг в реале должно быть быстрым (никто не позволит держать толпу пациентов перед регистратурой), на список накладываются доп. ограничения, например, отношениями "Многие-ко-многим" связываются услуги и отделения. Тогда оператор выбрав отделение получает небольшой список услуг, оказываемых именно этим отделением. Благодаря этому, скорость оформления такая-же, как в супермаркете. Некоторые услуги могут требовать и как-бы и опосредованной продажи каких-либо материальных ценностей (расходных материалов), например, импланты, линзы, реактивы, рентгеновская плёнка и т.п. Если в учреждении установлен модуль для ресурсного отдела, то программа может предложить и список имеющегося на складе (в отделении) мат. обеспечения этой услуги. Т.о. мы имеем актуальный склад и персонифицированный учёт мат.активов. Это в принципе должно быть в каждом мед.учреждении, поскольку, не дай бог, если придёт какая-либо "гнилая" партия имплантов, то мы отзовём не пол-города, а только несколько человек, у которых импланты из этой партии. А помимо этого, есть и хороший экономический эффект, если подключить ресурсный отдел. Уменьшаются запасы на складе, нет проблемы просроченного товара (те, кто работает в медицине знают, что это очень серьёзно), исчезает бардак. Далее, в некоторых учреждениях ведут персонифицированный учёт исполнителей услуг. В этом случае на каждую услугу "навешивается" гроздь должностей-исполнителей. На скрине можно видеть закладку "Услуга - Должности", где прописано должностное обеспечение выполнения услуги и тариф должности за выполнение услуги. Если будет интерес, выложу скрин. Далее, по факту выполнения услуги, специальный человек распределяет конкретных людей на исполнение услуги. Заранее, до исполнения это сделать можно только в единичных учреждениях, где железная дисциплина. В большинстве-же, кто дорос до этой схемы, по-факту. Тут тоже для исключения ошибок, учитывается, находится-ли человек в отпуске, какая у него квалификация, должность. В целом, БД построена так, что учёт выполнения услуг может работать как самостоятельное раб. место, сидит один кассир, выписывает квитанции и всё. Если-же в учреждении ввели электронную историю или электронную амбулаторну карту, то учёт услуг можно прицепить к этим документам. Фундаментального различия между платными-бесплатными нет. Просто есть поток услуг с признаками "Платный", "ДМС", "ОМС", "РОФСС" и т.д. Врачу на самом деле по-барабану, кто заплатит. А бухгалтерии плюшки ввиде учёта наличных, автоматическое формирование счетов, напр. для страховых компаний по ДМС и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.05.2012, 09:48 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=37801783&tid=1541673]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
151ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
59ms |
get tp. blocked users: |
1ms |
| others: | 207ms |
| total: | 460ms |

| 0 / 0 |
