내 팀이 고객을위한 전자 건강 플랫폼을 구축하기 위해 할당 된, 및 설계 과정에서 우리는이 딜레마에 도착했습니다 :HL7 RIM을 사용하거나 자체 데이터 모델을 롤업해야합니까?
우리는 데이터 모델에 대한 두 가지 옵션이의 HL7 RIM (참조 정보 모델) 또 하나는 아직 설계되지 않은 것입니다.
RIM은 광범위하게 문서화되었으며 매우 완벽하게 보이지만 복잡성과 명백한 느린 속도를 고려할 때 최상의 선택인지는 확실하지 않습니다.
고객의 요구 사항만을 고려하여보다 이해하기 쉽고 빨라질 수있는 좀 더 간단한 모델을 만들고 싶습니다.
당신은 어떻게 생각하십니까? HL7-RIM을 따라 가야합니까? 아니면 내 고객의 요구 사항에 대한 간단한 모델을 생각해야합니까?
정보 교환의 필요성에 따라 HL7 메시징 프로토콜 구현이 필요하므로 기본 모델과 별도로 해당 부분을 개발해야합니다.
HL7 RIM을 구현해야하는 이유가 많을수록 의료 데이터 측면에서 더 많은 유연성 (응용 프로그램의 "저장소 또는 데이터웨어 하우스"가 많을수록)이 필요합니다. 이 접근법에 대한 추가 정보는 "RIMBAA"(RIM 기반 응용 프로그램 아키텍처)를 검색하십시오.
응용 프로그램이 특정한 잘 정의 된 워크 플로 집합을 지원하도록 지향할수록 특정 워크 플로에 대해 최적화 된 데이터 모델을 사용해야하는 이유가 더 커집니다. John Saunders에 동의합니다. 최적화 된 데이터 모델을 RIM에 매핑 할 수 있는지 확인하십시오. 그러면 응용 프로그램의 미래를 보장하고 HL7 인터페이스를보다 쉽게 지원할 수 있습니다.
답변은 고객 요구 사항에 따라 고유 한 모델을 사용하는 것이지만 항상 HL7과 상호 교환 할 수있는 기능 요구 사항이 있습니다. 개발 프로세스 전반에 걸쳐 요구 사항을 테스트하십시오.
나는 HL7을 권장하지만 사용법에 관해 전략적이어야합니다. 이미 귀사에서 소프트웨어 시스템 전체를 사용하고 있다고 가정합니다. 그렇다면 핵심 서비스에 "HL7 인터페이스"가 노출되도록하는 것이 좋지만 조직에 특정한 정식 형식의 내부 대화 상자가 있어야합니다.
HL7의 위대한 점은 본질적으로 메시지 기반이므로 Business Proccessor Manager (BPM) 소프트웨어를 사용하면 모든 종류의 멋진 작업을 수행 할 수 있습니다. 비즈니스 소프트웨어는 HL7의 흐름 메시지가 관리됩니다.
"iWay Intelligent Adapter for HL7"또는 IBM의 WTX와 같이 다양한 "어댑터"에 대한 조사를 제안 할 수 있습니다. 이를 통해 전송 계층에서 HL7 메시징에 대해 걱정할 필요없이 작성해야하는 비즈니스 코드에 집중할 수 있습니다.
희망이 있습니다.
HL7은 "HL7 지원"이 의미없는 요구 사항이므로 고객이 철저히 사용자 정의합니다. "고객이 요구하는 방식으로 HL7 지원"과 같은 말을해야합니다. 아무것도 끊기지 않도록 끊임없이 테스트해야합니다. –
Interaction/MT 레벨에 맞으면 HL7 채택을 통치하는 여러 국가 표준 기관에 맡겨집니다. 국가 표준 조직이 모든 고객 도메인을 포착하지 않은 경우 "빈칸 채우기"는 고객의 몫입니다.그러나 개념, 방법론 및 데이터 유형은 도메인/구현간에 동일 할 것입니다. 본질적으로 "HL7"을 알고 있다면 고객과 고객간에 갈 수 있어야합니다. – ThaDon
제품과의 만남이 저에게 개발되고 지원되는 소프트웨어에 대한 의견을주었습니다 – zode64