いくつかのHL7関連プロジェクトでNHapiを使用することを検討しています。通常、プロジェクトでオープンソースライブラリを使用することにした場合、次の2つの基準があります。
- ユーザーベースの広さ。
- サポートの質。
SourceForgeのNHapiフォーラムを見ると、上記の2つの基準のいずれも満たしていないようです。
他のオプションは、商用製品を購入するか、パーサーを作成することです。
NHapiを使用することについての提案や考えはありますか?
いくつかのHL7関連プロジェクトでNHapiを使用することを検討しています。通常、プロジェクトでオープンソースライブラリを使用することにした場合、次の2つの基準があります。
SourceForgeのNHapiフォーラムを見ると、上記の2つの基準のいずれも満たしていないようです。
他のオプションは、商用製品を購入するか、パーサーを作成することです。
NHapiを使用することについての提案や考えはありますか?
一部のHL7処理アプリケーションでNHAPIの実装を開始しました。私たちはあなたと同じ懸念を抱いていましたが、それがオープンソースであることを考えると、独自のパーサーを作成するよりも確かに便利です。それとそれが基づいているHAPIプロジェクトはMPLの下でライセンスされているので、プロジェクトがニーズを満たしていないことがわかった場合は、いつでもコードベースをフォークできます。
名前を忘れてしまった商品も使っていますが、それが課題となっています。特に新しいオペレーティングシステムでは、インストールとライセンス供与が課題であり、同社は製品を重視していないため、サポートは非常に貧弱です。
また、サードパーティの使用法が少なくとも少しあることもわかりました:http: //dib0.nl/code/255-where-to-begin-if-you-want-to-start-with- hl7-in-c-or-java
NHAPIを評価し、あなたが引用したのと同じ懸念事項には使用しないことにしました。代わりに、HL7Spyを使用しました。メッセージを送信するための便利なGUIクライアント(テストに便利)と、メッセージの作成に役立つDLLがあります。
残念ながら、あなたが言ったように、それは商用製品であり、オープンソースではありません。しかし、私たちはそれにかなり満足しています。
統合エンジンで使用することにしました。私の印象:
異なるHL7バージョン(V231およびV230)を使用すると、APIオブジェクトモデルが混乱し、均質ではないことがわかりました。
また、テキストメッセージを解析するときにいくつかのバグが見つかりました。
IMHO NHAPIは信頼性が低いわけではありませんが、使用する前に、NHAPIが必要なすべてのユースケースをテストするためにAPIを評価してください。
NHAPIでのすべての経験の後で、100%確実に言えることは、時間があれば、独自のHL7APIを開発したであろうということです。
お役に立てれば。