Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.cplire.ru/rus/telemed/rpr/ReportIV.doc Дата изменения: Wed Dec 18 17:46:00 2002 Дата индексирования: Tue Oct 2 07:23:41 2012 Кодировка: koi8-r Поисковые слова: http www.astronomy.ru forum index.php topic 4644.0.html

Научно-исследовательский центр электронных диагностических систем "ЭЛДИС"
РАН (НИЦ ЭЛДИС РАН)





ОТЧЕТ


по государственному контракту
от 1 февраля 2002 г. ? 37.029.11.0028


по теме «Методы передачи медицинской информации, включая графическую, в
телекоммуникационных сетях телемедицины» федеральной целевой-научно-
технической программы «Исследования и разработки по приоритетным
направлениям развития науки и техники» на 2002-2006 годы, Блок 1, Раздел -
«Информационные технологии и электроника» (на 2002 год).


(годовой)





















Москва 2002 г.

Прототипы стандартов для системы регистрации и обследования больных
(XML-cловари описания данных- для конкретной области медицины)



На IV этапе выполнения проета основная работа была связана с вопросами
реализации структуры стандартов. Как отмечалось ранее, методология
систематического процесса разработки функциональных стандартов представляет
собой типичный цикл разработки сложного информационного проекта, состоящего
из фазы выработки требований (ТЗ) - фазы анализа - фазы реализации. На
данном этапе основное внимание уделялось вопросам фазы реализации, более
конкретно - созданию функционадьных стандартов на основе XML-cловарей
описания данных. Реализация осуществлена для подсистемы регистрации и
обследования больных. При этом преследовалось две цели:

. продемонстрировать общую методологию построения функционадьных
стандартов на конкретном примере

. реализовать функционадьные стандарты для подсистемы регистрации и
обследования, которая является необходимой часьтью любой системы
телемедицины

При реализации функционадьных стандартов принимались во внимание
следующие общие рекомендации методология разработки: совместимость с HL7
версии 3.0, качество стандартов, время реализации стандартов. Совместимость
с HL7 разработанных стандартов гарантируется следующими положениями,
реализованными при разработке:

. использована спецификация HL7 для структуры содержания сообщений

. использована RIM модель для реализации объектной модели стандартов

. разработка модели сообщений основана на Use-Case анализе

. при разработке стандартов использовались элементы объектно-
ориентированного подхода для создания DTD-словарей определения данных

Качество стандартов предполагается высоким, поскольку стандарты
основаны на всестороннем анализе предметной области. Практическая проверка
и тестирование разработанных стандартов планируется на последующих этапах
проекта, при условии его пролонгации, со всеми заинтересованными
соисполнителями проекта.

По мере выполнения проекта выявлены реальные временные рамки реализации
стандартов. Реальная работа реализации функционадьных стандартов для
подсистемы регистрации и обследования (не включающая этапы исследования
методологии и выбора технологии реализации) заняла, включая фазы выработки
требований (ТЗ), анализа и реализации, около четырех месяцев. На основе
данного результата, с учетом накопленного опыта, можно оценивать время
реализации для других подсистем специализированных систем телемедицины.

Функциональные стандарты для системы регистрации и обследования

Назначение

Предлагаемые стандарты имеют своей целью продемонстрировать общую
методологию построения функциональных стандартов на конкретном примере
подсистемы регистрации и обследования больных и сформировать предложение по
их использованию в реальных системах телемедицины.

Неформализованное описание

Система регистрации и обследования больных предназначается для
автоматизации следующего стандартного медицинского процесса. Пациент,
имеющий специфические жалобы на состояние здоровья, направляется в клинику
своим лечащим терапевтом (GP). Его регистрирует (сообщение о регистрации
ADT^A04) и принимающий врач (MD) запрашивает диагностическую лабораторию
провести определенные анализы данного больного (запрос на анализы ORM^O01).
Предполагается, что лаборатория находится за пределами клиники. В момент,
когда лабораторией получен запрос автоматически генерируется сообщение
клинике, подтверждающее получение запроса (сообщение ORR^O02).
Подтверждение высылается даже в случае невозможности выполнения
анализа/анализов. В случае готовности выполнить анализы, образцы для
анализа (например крови), взятые у больного, переправляются в лабораторию
и информация об этом заносится в информационную систему. Клиника также
снабжает лабораторию дополнительной информацией из истории болезни
(например данными о аллергии и т.д.) и детализацией о специфике анализа
(указанием необходимых тестов) на основе стандартов HL7. В момент, когда
результаты анализов готовы, лаборатория направляет их в клинику и лечащему
терапевту (сообщение ORU^R01).


[pic]Рис 1 Схема системы регистрации и обследования больных

На рис.1 приведена принципиальная статическая схема передачи сообщений
в системе регистрации и обследования больных. Блоки "HL7 совм. интерф."
отвечают за преобразование специфичных для каждого из приложений форматов
данных в общие для всех функциональные стандарты. На рис.2 приведена
динамическая схема обмена сообщениями (модель взаимодействия). На данной
схеме отражена очередность обмена сообщениями в системе регистрации и
обследования больных.

[pic]

Рис 2 Схема обмена сообщениями в системе регистрации и обследования
больных.


Формализованное описание

Интерфейсы системы функциональных стандартов
(Use Case модель)

Требования к функциональным стандартам оформлены в виде диаграмм
использования (Use Case diagrams) на основе анализа неформализованного
описания. Самостоятельное значение Use Case модели заключается в том, что
все заинтересованные стороны - эксперты, аналитики, разработчики могут
сформировать ясное представление о системе в терминах ее границ и
фунциональности - совокупности задач, решаемых непосредственно данной
системой. Далее приводится подробное описание прецендента «Заказ (запрос)
на проведение диагностических анализов».





Заказ (запрос) на проведение диагностических анализов

Use Case прецендент

Назначение сообщения Заказа на проведение диагностических анализов
состоит в том, чтобы положить начало обмену сообщениями о ходе выполнения
данного заказа. В число последующих возможных сообщений могут входить
регистрация заказа, включая принятие его к выполнению, отказ от закза,
отсрочка в выполнении, исправление заказа и т.д. Далее для простоты
рассматривается только ситуация принятие заказа к выполнению.

Содержание сообщения должно включать информацию идентифицирующую
пациента и его местонахождение. Кроме того оно должно содержать информацию
о специфике выполняемого анализа и о том, когда анализ должен быть готов.
Также в заказ могут быть включены результаты предыдущих анализов, которые
предоставляют дополнительную информацию.



[pic]


Принимающий врач принимает решение о проведении анализов и инициирует
процесс заказа, взаимодействуя с Системой отправки заказа. Системой
отправки переправляет Сообщение Заказа на проведение диагностических
анализов. Система подтверждения впоследствии подтверждает принятие заказа к
выполнению.




1. принимающий врач (MD)- принимает решение о проведении анализов и
инициирует процесс заказа анализов для данного пациента.
2. система отправки заказа на анализы - ответственна за передачу
сообщения в соответствующую систему диагностической лаборатории.
3. система подтверждения заказа - ответственна за передачу сообщения
подтверждения получения заказа

Предусловия для прецендента:

1. Принимающий врач принял решение о проведении конкретных анализов и
оформил их заказ посредством ввода его в Систему отправки.

Последовательность сообщений прецендента:

1. Система отправки (клиники) переправляет сообщение о заказе (ORM) в
соответствующую лабораторию.


2. Система подтверждения заказа (лаборатории) возвращает подтверждение
(ORR), которое уведомляет о возможности выполнения заказа.


Постусловия для прецендента:

1. Диагностическая лаборатории уведомлена о новом заказе на анализы.


2. Клиническая информационная система уведомлена, что заказ принят на
выполнение.

Стандарты сообщений:

1. ORM^O01 {(должен быть определен ID структуры)}


2. ORR^O02{(должен быть определен ID структуры)}


Определение статических параметров:

ORM^O01 {(должен быть определен ID структуры)}

1. Параметры уровня сообщения - в форме DTD
2. Параметры уровня сегмента - в форме DTD
3. Параметры уровня полей - в форме DTD для типов данных, значений, кодов и
текста.

ORR^O01 {(должен быть определен ID структуры)}

1. Параметры уровня сообщения - в форме DTD
2. Параметры уровня сегмента - в форме DTD
3. Параметры уровня полей - в форме DTD для типов данных, значений, кодов и
текста.



Динамическое поведение для функциональных стандартов
(Модель взаимодействия)


Построение модели взаимодействия сообщений (Interaction Model)
основывается на анализе динамического поведения системы. Взаимодействия
определяют те инициирующие события (trigger events), которые запускают
обмен информацией и необходимые для каждой ситуации сообщения.


Модель взаимодействия строится на основе определения класов ролей
(application role classes), таблиц взаимодействия и диаграмм
последовательностей. Она должна быть согласована с разработанными
вариантами использования (Use Cases) и сценариями. Далее приводится
подробное описание модели взаимодействия, связанной с прецендентом «Заказ
(запрос) на проведение диагностических анализов».


Заказ (запрос) на проведение диагностических анализов


Диаграмма взаимодействия
[pic]
Определение динамических параметров


1. Для ORM^O01: AccNE_AppAL


2. Для ORR^O02: AccNE_AppNE

Где AccNE_AppAL и AccNE_AppNE параметры требований подтверждения получения.

Стандарт HL7 предусматривает два типа требований подтверждения получения
отправленных сообщений.
1. Требование подтверждения получения (Acc) (генерируемое автоматически)
2. Требование подтверждения получения приложениеем (App) (например
подтверждение получения приложением запроса ORR^O02)
AccNE (отдельно не подтверждать получение) - это требование, которое
означает, что получателю нет необходимости специально подтверждать
получение исходного сообщения. Если приложение использует AppAL сообщение
(с требованием всегда подтверждать получение приложениеем), использование
Acc становится избыточным, следовательно можно использовать связку AccNE_
AppAL. AccNE_AppNE не требует от получателя вообще никакого подтверждения,
иначе может получиться замкнутый круг типа: «-подтверждаю, что получено
ваше сообщение, - подтверждаю, что получено ваше подтверждение о получении
сообщения - подтверждаю, что получено ваше подтверждение о подтверждении о
получении сообщения...» и так далее.

Примеры XML-cловарей описания сообщений/сегментов/данных ORM^O01/ ORR^O01
(стандартов), построенных на основе приведенного выше анализа-спецификации
и реализованные в виде файлов DTD (Data Type Definitions) - XML метаданных
- приведены в приложении к отчету.




Руководитель проекта
Д.ф.м.н. Обухов Ю.В.
































Приложение


XML-cловари описания сообщений/сегментов/данных ORM^O01/ ORR^O01




1. Date Types DTD.

Содержит описание типов данных, которые используються в сообщениях.

AlternateIdentifier? , AlternateText? , NameOfAlternateCodingSystem? )>

AlternateIdentifier? , AlternateText? , NameOfAlternateCodingSystem? )>



















)>























Prefix? , Degree? )>













ParentObservationValue? )>







BodySite? , SiteModifier? )>











ExplicitTimeInterval* , Duration? , StartDateTime? , EndDateTime? ,
Priority? , Condition? , Text_Value? , Conjunction? , SequenceResultsFlag?
, PlacerOrderNumber? , PlacerFillerNumber? , SequenceConditionValue? ,
MaximumNumberOfRepeats? )>











































)>
















InternalVersion )>

UniversalIDType )>

UniversalIDType )>

)>

LocationStatus , PersonLocationType , Building , Floor ,
LocationDescription )>













































CodeIdentifyingTheCheckDigitSchemeEmployed , AssigningAuthority )>

, MiddleInitialOrName , Suffix , Prefix , Degree , SourceTable ,
AssigningAuthority )>

IdentifierTypeCode , AssigningFacility )>

LastNamePrefix? , NameTypeCode , IdentifierCheckDigit ,
CodeIdentifyingTheCheckDigitSchemeEmployed , IdentifierTypeCode ,
AssigningFacility , NameRepresentationCode )>






'CK.3' >




















StateOrProvince , ZipOrPostalCode , Country , AddressType ,
OtherGeographicDesignation )>



AddressRepresentationCode )>

NameRepresentationCode )>

(OrganizationName , OrganizationNameTypeCode , CompositeIDWithCheckDigit ,
IdentifierTypeCode , AssigningFacilityID , NameRepresentationCode )>
#FIXED 'XON' >
TelecommunicationUseCode , TelecommunicationEquipmentType , EmailAddress ,
CountryCode , AreaCityCode , PhoneNumber , Extension , AnyText )>



















































ChannelName , ElectrodeNames , ChannelSensitivityUnits ,
CalibrationParameters , SamplingFrequency , MinimumMaximumDataValues )>





Sample CDATA #REQUIRED
Channel CDATA #REQUIRED >



ValueNumber CDATA #REQUIRED >
Encoding , Data )>




























RangeUnits , RangeType )>





















Value , RelationalConjunction )>





MaximumColumnWidth )>














IssuingStateProvinceCountry , ExpirationDate )>



EndHourRange )>




















DateTimeActionPerformed )>




















2. Common Segments DTD.

Содержит описание основных сегментов сообщений.


%Profile_Fields;


ErrorCondition )>

SendingApplication , ReceivingApplication? , DateTimeOfMessage? ,
MessageType , MessageControlID , ProcessingID , VersionID ,
AcceptAcknowledgementType , ApplicationAcknowledgementType , CountryCode?
)>




3. Field DTD.

Содержит описание полей сообщений.


%Profile_DataTypes;






































































































































































































'RXE.7'>
(CodedElement )>
CDATA #FIXED 'RXE.'>
































4. ORMO01 New Diagnostic Study Order DTD.

Описывает структуру сообщения о новом заказе на проведение анализов.


%Common_Segments;

PatientIdentification , PatientVisit, CommonOrder )>


, PatientID-InternalID+ , AlternatePatientID* , PatientName ,
MothersMaidenName? , DateOfBirth? , Sex? , PatientAlias* , Race? ,
PatientAddress* , PhoneNumber-Home* , PhoneNumber-Business* ,
PrimaryLanguage? , MaritalStatus? , Religion? , PatientAccountNumber? ,
SSNNumber-Patient? , DriversLicNum-Patient? , BirthPlace? , Citizenship* ,
VeteransMilitaryStatus? )>

PriorPatientLocation? , TemporaryLocation? , PendingLocation? ,
PriorTemporaryLocation? )>

PlacerOrderNumber? , FillerOrderNumber? , PlacerGroupNumber? , OrderStatus?
, QuantityTiming? , Parent? , DateTimeOfTransaction? , EnteredBy? ,
VerifiedBy? , OrderingProvider? , EnterersLocation? , CallbackPhoneNumber*
, OrderControlCodeReason? , EnteringOrganization? )>

ObservationRequest? , PlacerOrderNumber? , FillerOrderNumber? ,
UniversalServiceID , ObservationDateTime? , ObservationEndDateTime? ,
CollectionVolume? , CollectorIdentifier* , SpecimenActionCode? ,
DangerCode? , RelevantClinicalInfo? , SpecimenReceivedDateTime? , OBR-
SpecimenSource? , OrderingProvider* , OrderCallbackPhoneNumber* ,
PlacerField1? , PlacerField2? , FillerField1? , FillerField2? ,
ResultsRptStatusChngDateTime? , DiagnosticServSectID? , ResultStatus? , OBR-
ParentResult? , ParentNumber? , TransportationMode? , ReasonForStudy* )>

ValueType , ObservationIdentifer , ObservationSub-ID? , ObservationValue? ,
Units? , ReferencesRange? , AbnormalFlags* , ObservResultStatus ,
DateTimeOfTheObservation? , ProducersID? , ResponsibleObserver? )>


5. ORMO01 Cancel Diagnostic Study Order DTD.

Описывает структуру сообщения об отмене сделаного ранее заказа.

%Common_Segments;

PatientIdentification , PatientVisit , CommonOrder )>


, PatientID-InternalID+ , AlternatePatientID* , PatientName ,
MothersMaidenName? , DateOfBirth? , Sex? , PatientAlias* , Race? ,
PatientAddress* , PhoneNumber-Home* , PhoneNumber-Business* ,
PrimaryLanguage? , MaritalStatus? , Religion? , PatientAccountNumber? ,
SSNNumber-Patient? , DriversLicNum-Patient? , BirthPlace? , Citizenship* ,
VeteransMilitaryStatus? )>

PriorPatientLocation? , TemporaryLocation? , PendingLocation? ,
PriorTemporaryLocation? )>

PlacerOrderNumber? , FillerOrderNumber? , PlacerGroupNumber? , OrderStatus?
, QuantityTiming? , Parent? , DateTimeOfTransaction? , EnteredBy? ,
VerifiedBy? , OrderingProvider? , EnterersLocation? , CallbackPhoneNumber*
, OrderControlCodeReason? , EnteringOrganization? )>

ObservationRequest? , PlacerOrderNumber? , FillerOrderNumber? ,
UniversalServiceID , ObservationDateTime? , ObservationEndDateTime? ,
CollectionVolume? , CollectorIdentifier* , SpecimenActionCode? ,
DangerCode? , RelevantClinicalInfo? , SpecimenReceivedDateTime? , OBR-
SpecimenSource? , OrderingProvider* , OrderCallbackPhoneNumber* ,
PlacerField1? , PlacerField2? , FillerField1? , FillerField2? ,
ResultsRptStatusChngDateTime? , DiagnosticServSectID? , ResultStatus? , OBR-
ParentResult? , ParentNumber? , TransportationMode? , ReasonForStudy* )>

ObservationSub-ID? , ObservationValue? , Units? , ObservResultStatus ,
DateTimeOfTheObservation? )>


6. ORRO02 Diagnostic Study Order Accepted DTD

Описывает структуру сообщения о том, что заказ был получен.


%Common_Segments;

MessageAcknowledgement, PatientIdentification , CommonOrder )>


InternalID+ , PatientName , MothersMaidenName? , DateOfBirth? , Sex? ,
PatientAddress* , SSNNumber-Patient? , BirthPlace? )>

FillerOrderNumber? )>


7. ORRO02 Diagnostic Study Order Cancelled DTD

Описывает структуру сообщения о том, что заказ был отменен


%Common_Segments;

MessageAcknowledgement, PatientIdentification , CommonOrder )>
'ORR.O02' >

InternalID+ , PatientName , MothersMaidenName? , DateOfBirth? , Sex? ,
PatientAddress* , SSNNumber-Patient? , BirthPlace? )>

FillerOrderNumber? )>


8. ORRO02 Diagnostic Study Order Cancelled As Requested DTD.

Описывает структуру сообщения о том, что заказ был отменен при запросе.


%Common_Segments;

MessageAcknowledgement, PatientIdentification , CommonOrder, )>
#FIXED 'ORR.O02' >

InternalID+ , PatientName , MothersMaidenName? , DateOfBirth? , Sex? ,
PatientAddress* , SSNNumber-Patient? , BirthPlace? )>

FillerOrderNumber? )>


9. ORRO02 Unable To Accept Diagnostic Study Order DTD

Описывает структуру сообщения о том, что заказ на проведение анализов задан
в неправильной форме.


%Common_Segments;

MessageAcknowledgement, CommonOrder )>
'ORR.O02' >


FillerOrderNumber? )>


10. ORRO02 Unable To Cancel Diagnostic Study Order DTD.

Описывает структуру сообщения о том, что запрос на омену заказа анализов
задан в неправельной форме.


%Common_Segments;

MessageAcknowledgement, PatientIdentification , CommonOrder, )>
'ORR.O02' >

InternalID+ , PatientName , MothersMaidenName? , DateOfBirth? , Sex? ,
PatientAddress* , SSNNumber-Patient? , BirthPlace? )>

FillerOrderNumber? )>


11. ORUR01 Unsolicited Transmission Of Observation Results DTD.

Описывает структуру незатребованного (автоматического) сообщения о
резутьтатах анализов.


%Common_Segments;

(MessageHeaderSegment , PatientIdentification , CommonOrder )>
#FIXED 'ORU.R01' >


PatientId-ExternalID? , PatientID-InternalID+ , AlternatePatientID* ,
PatientName , MothersMaidenName? , DateOfBirth? , Sex? , PatientAlias* ,
Race? , PatientAddress* , PhoneNumber-Home* , PhoneNumber-Business* ,
PrimaryLanguage? , MaritalStatus? , Religion? , PatientAccountNumber? ,
SSNNumber-Patient? , DriversLicNum-Patient? , BirthPlace? , Citizenship* ,
VeteransMilitaryStatus? )>

PriorPatientLocation? , TemporaryLocation? , PendingLocation? ,
PriorTemporaryLocation? )>

PlacerOrderNumber? , FillerOrderNumber? , PlacerGroupNumber? , OrderStatus?
, QuantityTiming? , Parent? , DateTimeOfTransaction? , EnteredBy? ,
VerifiedBy? , OrderingProvider? , EnterersLocation? , CallbackPhoneNumber*
, OrderControlCodeReason? , EnteringOrganization? )>

ObservationRequest? , PlacerOrderNumber? , FillerOrderNumber? ,
UniversalServiceID , ObservationDateTime? , ObservationEndDateTime? ,
CollectionVolume? , CollectorIdentifier* , SpecimenActionCode? ,
DangerCode? , RelevantClinicalInfo? , SpecimenReceivedDateTime? , OBR-
SpecimenSource? , OrderingProvider* , OrderCallbackPhoneNumber* ,
PlacerField1? , PlacerField2? , FillerField1? , FillerField2? ,
ResultsRptStatusChngDateTime? , DiagnosticServSectID? , ResultStatus? , OBR-
ParentResult? , ParentNumber? , TransportationMode? , ReasonForStudy* )>

ValueType , ObservationIdentifer , ObservationSub-ID? , ObservationValue? ,
Units? , ReferencesRange? , AbnormalFlags* , ObservResultStatus ,
DateTimeOfTheObservation? , ProducersID? , ResponsibleObserver? )>
-----------------------
актеры

Use-case